Est-ce que GET ou POST est plus sûr que l'autre?

Lorsqu'on compare un accès HTTP à un post HTTP, quelles sont les différences d'un point de vue de la sécurité? Est l'un des choix intrinsèquement plus sûr que les autres? Si oui, pourquoi?

je me rends compte que POST n'expose pas l'information sur L'URL, mais y a-t-il une valeur réelle dans cela ou est-ce juste la sécurité par l'obscurité? Y a-t-il une raison pour laquelle je préférerais un poste lorsque la sécurité est un problème?

Edit:

Sur HTTPS, les données POST sont encodées, mais les URLs peuvent-elles être reniflées par un tiers? En outre, je traite avec JSP; lors de l'utilisation de JSP ou un cadre similaire, serait-il juste de dire que la meilleure pratique est d'éviter de placer des données sensibles dans le POST ou obtenir tout à fait et en utilisant le code côté serveur pour traiter les informations sensibles à la place?

264
demandé sur James McMahon 2008-10-13 22:08:01
la source

25 ответов

en ce qui concerne la sécurité, ils sont intrinsèquement les mêmes. Bien qu'il soit vrai que POST n'expose pas d'informations via L'URL, il expose tout autant d'informations qu'une GET dans la communication réseau réelle entre le client et le serveur. Si vous avez besoin de passer des informations qui sont sensibles, votre première ligne de défense serait de passer en utilisant HTTP Sécurisé.

obtenir ou les messages de chaîne de requête sont vraiment bons pour l'information requise pour soit bookmarking un élément particulier, ou pour aider à l'optimisation des moteurs de recherche et l'indexation des éléments.

POST est bon pour les formulaires standard utilisés pour soumettre des données en une seule fois. Je ne voudrais pas utiliser GET pour l'affichage de formulaires réels, à moins que peut-être dans un formulaire de recherche où vous voulez permettre à l'utilisateur de sauvegarder la requête dans un signet, ou quelque chose le long de ces lignes.

194
répondu stephenbayer 2008-10-13 22:16:37
la source

la requête GET est légèrement moins sécurisée que la requête POST. Ni l'un ni l'autre n'offre la vraie "sécurité" par lui-même; en utilisant les requêtes de poste ne sera pas magiquement rendre votre site Web sécurisé contre les attaques malveillantes d'un montant appréciable. Cependant, l'utilisation des requêtes GET peut rendre une application par ailleurs non sécurisée.

Le mantra que "vous ne devez pas utiliser des demandes pour faire des changements" est encore très valable, mais cela a peu à voir avec le comportement malveillant . Les formulaires de connexion sont les plus sensibles à être envoyés en utilisant le mauvais type de demande.

Recherche des araignées et des accélérateurs web

C'est la vraie raison pour laquelle vous devez utiliser les requêtes POST pour changer les données. Les araignées de recherche suivront chaque lien sur votre site Web, mais ne soumettront pas de formulaires aléatoires qu'ils trouvent.

les Accélérateurs Web sont pires que les araignées de recherche, parce que ils s'exécutent sur la machine du client, et "cliquez sur" tous les liens dans le contexte de l'utilisateur connecté . Ainsi, une application qui utilise une requête GET pour supprimer des trucs, même si elle nécessite un administrateur, obéira volontiers aux ordres du (non-malicieux!) Web accelerator et supprimer tout ce qu'il voit .

Confondre adjoint attaque

Un confondre adjoint attaque (d'où le sous - est le navigateur) est possible indépendamment du fait que vous utilisez un GET ou une requête POST .

sur les sites Web contrôlés par l'attaquant obtenir et poster sont tout aussi facile à soumettre sans interaction avec l'utilisateur .

le seul scénario dans lequel le POST est légèrement moins susceptible est que de nombreux sites Web qui ne sont pas sous le contrôle de l'attaquant (par exemple, un forum tiers) permettent l'intégration arbitraire images (permettant à l'attaquant d'injecter une requête GET arbitraire), mais empêcher toutes les façons d'injecter une requête arbitary POST, qu'elle soit automatique ou manuelle.

on pourrait soutenir que les accélérateurs de toile sont un exemple d'attaque confus des députés, mais c'est juste une question de définition. Si quelque chose, un attaquant malveillant n'a aucun contrôle sur ce, il est donc à peine un attaque , même si le député est confus.

journaux du Proxy

Les serveurs mandataires

sont susceptibles d'enregistrer des URLs GET dans leur intégralité, sans enlever la chaîne de requête. Les paramètres des requêtes POST ne sont normalement pas journalisés. Il est peu probable que les Cookies soient connectés dans les deux cas. (exemple)

c'est un argument très faible en faveur de la poste. Premièrement, le trafic non crypté peut être enregistré dans son intégralité; un proxy malveillant a déjà tout ce dont il a besoin. Deuxièmement, la demande les paramètres sont d'une utilité limitée pour un attaquant: ce qu'ils ont vraiment besoin est les cookies, donc si la seule chose qu'ils ont sont les logs proxy, ils sont peu susceptibles d'être en mesure d'attaquer soit un GET ou une URL POST.

il y a une exception pour les demandes d'ouverture de session: elles contiennent généralement le mot de passe de l'utilisateur. Enregistrer ceci dans le log proxy ouvre un vecteur d'attaque qui est absent dans le cas de POST. Cependant, le login sur le HTTP simple est de toute façon intrinsèquement peu sûr.

Proxy cache

les proxies de mise en cache peuvent conserver les réponses GET, mais pas les réponses POST. Cela dit, les réponses GET peuvent être rendues inaccessibles avec moins d'effort que la conversion de L'URL en un gestionnaire de POST.

HTTP "Referer"

si l'utilisateur doit naviguer vers un site web tiers à partir de la page servie en réponse à une demande GET, ce site web tiers obtient de voir tous les paramètres GET request.

Appartient à la catégorie "révèle les paramètres de la requête à un tiers", dont la sévérité dépend de ce qui est présent dans ces paramètres. Les requêtes POST sont naturellement immunisées contre cela, mais pour exploiter la requête GET un hacker aurait besoin d'insérer un lien vers son propre site Web dans la réponse du serveur.

historique du navigateur

ceci est très similaire à l'argument "proxy logs": les requêtes GET sont stockées dans l'historique du navigateur avec leur paramètre. L'attaquant peut facilement les obtenir s'il a un accès physique à la machine.

actualiser de votre Navigateur, l'action

le navigateur rejoue une requête GET dès que l'utilisateur clique sur"refresh". Il pourrait le faire lors de la restauration des onglets après l'arrêt. Toute action (par exemple, un paiement) sera donc répétée sans avertissement.

le navigateur ne rejoue pas une requête POST sans avertissement.

C'est un bon raison de l'utiliser seulement en POST-demandes de modification de données, mais n'a rien à voir avec les comportements malveillants et, par conséquent, de la sécurité.

alors que dois-je faire?

  • utiliser uniquement les demandes de changement de données postées, principalement pour des raisons non liées à la sécurité.
  • N'utilisez que les requêtes POST pour les formulaires de connexion; sinon, introduisez les vecteurs d'attaque.
  • si votre site effectue des opérations sensibles, vous avez vraiment besoin quelqu'un qui sait ce qu'il fait, parce que ça ne peut pas être couvert par une seule réponse. Vous devez utiliser HTTPS, HSTS, CSP, mitigate SQL injection, script injection (XSS) , CSRF , et un million d'autres choses qui peuvent être spécifiques à votre plate-forme (comme la vulnérabilité d'assignation de masse dans divers cadres: ASP.NET MVC , Ruby on Rails , etc.). Il n'y a pas une seule chose qui va faire la différence entre "sécurisé" (non exploitables) et de la "non sécurisé".

sur HTTPS, les données POST sont encodées, mais les URLs peuvent-elles être reniflées par un tiers?

non, ils ne peuvent pas être reniflés. Mais les Url seront stockées dans l'historique du navigateur.

serait-il juste de dire que la meilleure pratique est d'éviter la possibilité de placer des données sensibles dans le courrier ou Obtenir tout à fait et en utilisant le code côté serveur pour traiter les informations sensibles à la place?

dépend de sa sensibilité, ou plus précisément, de quelle manière. Évidemment, le client le verra. Toute personne ayant un accès physique à l'ordinateur du client. Le client peut le mystifier en vous le renvoyant. Si ces question alors oui, conserver les données sensibles sur le serveur et ne pas la laisser partir.

414
répondu Roman Starkov 2018-06-08 19:15:04
la source

vous n'avez pas de plus grande sécurité fournie parce que les variables sont envoyées par HTTP POST que vous avez avec les variables envoyées par HTTP GET.

HTTP / 1.1 nous fournit un tas de méthodes pour envoyer une requête :

  • OPTIONS
  • GET
  • HEAD
  • POST
  • PUT
  • supprimer
  • TRACE
  • CONNECT

supposons que vous ayez le document HTML suivant en utilisant GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

que demande votre navigateur? Il demande:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

faisons maintenant semblant que nous avons changé cette méthode de requête en un POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

les deux de ces requêtes HTTP sont:

  • Not crypté
  • inclus dans les deux exemples
  • Peut être evesdroped, et sujet à des attaques de type MITM.
  • facilement reproduit par des tiers, et des bots de script.

Beaucoup navigateurs ne prennent pas en charge les méthodes HTTP autres que POST/GET.

Beaucoup navigateurs comportements de stocker l'adresse de la page, mais cela ne signifie pas que vous pouvez ignorer tout de ces autres questions.

à préciser:

Est l'une de nature, plus sécurisé puis d'une autre? Je me rends compte que POST n'expose pas l'information sur L'URL mais est-ce qu'il y a une valeur réelle dans cela ou est-ce juste la sécurité par l'obscurité? Quelle est la meilleure pratique ici?

c'est correct, parce que le logiciel que vous utilisez pour parler HTTP tend à stocker les variables de requête avec une méthode mais pas un autre empêche seulement quelqu'un de regarder l'histoire de votre navigateur ou une autre attaque naïve d'un 10 ans qui pense qu'ils comprennent h4x0r1ng, ou des scripts qui vérifient votre magasin d'histoire. Si vous avez un script qui peut vérifier votre magasin d'histoire, vous pourriez tout aussi facilement en avoir un qui vérifie votre trafic réseau, donc toute cette sécurité à travers l'obscurité n'est que fournir l'obscurité aux enfants de script et aux petites amies jalouses.

sur https, POST data est codé, mais pourrait urls être espionné par une 3ème partie?

voici comment fonctionne SSL. Tu te souviens des deux demandes que j'ai envoyées? Voici à quoi ils ressemblent dans SSL: (J'ai changé la page en https://encrypted.google.com / as example.com ne répond pas sur SSL).

POST over SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`[email protected]?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%[email protected]/O/o/[email protected]&_o
9q1/?qyOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4"151930920"sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ [email protected]&
Pw?os9Od!c?/bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

get over SSL

rV/O8ow1pc`?058/8OS_Qy/oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&[email protected] f $)/xvxfgO'[email protected]&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(note: j'ai converti l'hexagone en ASCII, certains cents cinquante et une million neuf cent soixante mille neuf cent vingt"

toute la conversation HTTP est cryptée, la seule partie visible de la communication se trouve sur la couche TCP/IP (c'est-à-dire l'adresse IP et les informations du port de connexion).

alors laissez-moi faire une grande déclaration audacieuse ici. Votre site web n'est pas fourni une plus grande sécurité sur une méthode HTTP que ce n'est une autre, les hackers et les newbs dans le monde entier savent exactement comment faire ce que je viens de démontrer ici. Si vous voulez sécurité, utilisez SSL. Les navigateurs ont tendance à stocker l'histoire, il est recommandé par RFC2616 9.1.1 de ne pas utiliser GET pour effectuer une action, mais de penser que POST fournit la sécurité est tout à fait faux.

la seule chose que POST est une mesure de sécurité vers? Protection contre votre ex jalouse en feuilletant l'historique de votre navigateur. C'est tout. Le reste du monde est connecté à votre compte se moquer de vous.

pour démontrer pourquoi la poste n'est pas sécurisée, Facebook utilise des requêtes POST partout, alors comment un logiciel tel que FireSheep peut-il exister?

Notez que vous pouvez être attaqué avec CSRF même si vous utilisez le protocole HTTPS et votre site ne contiennent pas de XSS des vulnérabilités. En bref, ce scénario d'attaque suppose que la victime (l'utilisateur de votre site ou d'un service) est déjà connecté et dispose d'un cookie et puis le navigateur de la victime est demandé de le faire quelque chose avec votre (soi-disant sécurisé) site. Si vous n'avez pas de protection contre CSRF, l'attaquant peut encore exécuter des actions avec les identifiants des victimes. L'attaquant ne peut pas voir la réponse du serveur parce qu'elle sera transférée dans le navigateur de la victime, mais le dommage est généralement déjà fait à ce moment-là.

167
répondu Incognito 2013-05-13 13:37:08
la source

il n'y a pas de garantie supplémentaire.

les données Post n'apparaissent pas dans l'historique et/ou les fichiers journaux mais si les données doivent être conservées en sécurité, Vous avez besoin de SSL.

Sinon, quiconque renifle le fil peut lire vos données de toute façon.

32
répondu Jacco 2008-10-13 22:11:20
la source

même si POST ne donne aucun avantage réel de sécurité par rapport à GET , pour les formulaires de connexion ou tout autre formulaire avec des informations relativement sensibles, assurez-vous que vous utilisez POST comme:

  1. L'information POST ed ne seront pas enregistrées dans le mode histoire.
  2. les informations sensibles (mot de passe, etc.) envoyé dans le formulaire ne sera pas visible plus tard dans la barre D'URL (en utilisant GET , il sera visible dans l'histoire et la barre d'URL).

aussi, GET a une limite théorique de données. Pas POST .

pour de vraies informations sensibles, assurez-vous d'utiliser SSL ( HTTPS )

27
répondu Andrew Moore 2008-10-13 22:16:19
la source

ni L'un ni L'autre de GET and POST n'est intrinsèquement "plus sûr" que l'autre, tout comme ni l'un du télécopieur et du téléphone n'est "plus sûr" que l'autre. Les différentes méthodes HTTP sont fournies afin que vous puissiez choisir celle qui est la plus appropriée pour le problème que vous essayez de résoudre. OBTENIR est plus approprié pour idempotent requêtes tandis que le POST est plus approprié de "l'action" des requêtes, mais vous pouvez tirer dans le pied tout aussi bien avec l'un d'eux si vous Je ne comprends pas l'architecture de sécurité de l'application que vous maintenez.

il est probablement préférable si vous lisez Chapitre 9: définitions de méthode du HTTP/1.1 RFC pour obtenir une idée globale de ce que GET et POST ont été initialement prévus ou signifient.

18
répondu Mihai Limbășan 2008-10-13 22:37:44
la source

la différence entre GET et POST ne doit pas être considérée en termes de sécurité, mais plutôt dans leurs intentions envers le serveur. GET ne devrait jamais modifier les données sur le serveur - du moins pas dans les logs - mais POST peut créer de nouvelles ressources.

Nice procurations ne cache de données de POSTES, mais ils peuvent mettre en cache des données de l'URL, donc on pourrait dire que le POST est censé être plus sûr. Mais les données POST seraient toujours disponibles pour les mandataires qui ne fonctionnent pas bien.

comme mentionné dans de nombreuses réponses, le seul pari sûr est via SSL.

mais assurez-vous que les méthodes GET ne propagent aucun changement, comme supprimer des lignes de base de données, etc.

15
répondu ruquay 2008-10-14 00:05:23
la source

ma méthode habituelle pour choisir est quelque chose comme:

  • GET pour les articles qui seront récupéré plus tard par URL
    • E. G. La recherche doit être obtenir de sorte que vous pouvez faire la recherche.le php?S = XXX plus tard sur
  • POST pour les articles qui seront envoyé
    • C'est relativement invisible comapred à obtenir et plus difficile à envoyer, mais les données peuvent encore être envoyées via cURL.
6
répondu Ross 2008-10-13 22:11:50
la source

ce n'est pas lié à la sécurité mais... navigateurs ne met pas en cache les requêtes POST .

6
répondu Daniel Silveira 2008-10-13 23:05:06
la source

ni L'un ni l'autre ne confère de sécurité par magie à une demande, mais GET implique certains effets secondaires qui empêchent généralement de l'être.

OBTENIR l'Url de s'afficher dans l'historique du navigateur et le serveur web des journaux. Pour cette raison, ils ne devraient jamais être utilisés pour des choses comme les formulaires de connexion et les numéros de carte de crédit.

cependant, le simple fait de poster ces données ne le rend pas plus sûr. Pour cela, vous voulez SSL. À la fois obtenir et POST envoyer des données en clair sur le télégraphie LORSQU'il est utilisé sur HTTP.

il y a d'autres bonnes raisons de poster des données, aussi - comme la possibilité de soumettre des quantités illimitées de données, ou cacher des paramètres aux utilisateurs occasionnels.

l'inconvénient est que les utilisateurs ne peuvent pas marquer les résultats d'une requête envoyée par la poste. Pour cela, vous devez OBTENIR.

6
répondu edebill 2008-10-14 00:11:32
la source

considérez cette situation: une API négligée accepte les requêtes GET comme:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

dans certains paramètres, lorsque vous demandez cette URL et s'il y a une erreur/avertissement concernant la demande, toute la ligne est journalisée dans le fichier journal. Pire encore: si vous oubliez de désactiver les messages d'erreur dans le serveur de production, cette information est juste affiché en clair dans le navigateur! Vous venez de donner votre clé API à tout le monde.

malheureusement, il y a une vraie API qui fonctionne comme ça.

je n'aime pas l'idée d'avoir des informations sensibles dans les journaux ou de les afficher dans le navigateur. POST et GET n'est pas la même. Utilisation de chacun, le cas échéant.

5
répondu Halil Özgür 2011-12-22 13:26:20
la source
  1. de la SÉCURITÉ la sécurité des données EN TRANSIT: pas de différence entre la POSTE et l'OBTENIR.

  2. de SÉCURITÉ de sécurité de données SUR L'ORDINATEUR: le POST est plus sûr (pas d'URL de l'histoire)

3
répondu kashmiri 2009-08-19 08:36:35
la source

la notion de sécurité n'a de sens que si vous définissez ce contre quoi vous voulez être en sécurité.

si vous voulez être en sécurité contre l'historique stocké du navigateur, certains types de journalisation, et les gens qui regardent vos URLs, puis POST est plus sûr.

si vous voulez être en sécurité contre quelqu'un qui renifle votre activité réseau, alors il n'y a pas de différence.

2
répondu Taymon 2012-04-18 00:32:28
la source

beaucoup de gens adoptent une convention (à laquelle fait allusion Ross) selon laquelle les requêtes GET ne récupèrent que des données, et ne modifient aucune donnée sur le serveur, et les requêtes POST sont utilisées pour toutes les modifications de données. Alors que l'un n'est pas plus intrinsèquement sécurisé que l'autre, si vous do suivez cette convention, vous pouvez appliquer la logique de sécurité transversale (par exemple, seules les personnes ayant des comptes peuvent modifier les données, de sorte que les messages non authentifiés sont rejetés).

1
répondu Eric R. Rath 2008-10-13 22:19:05
la source

il est plus difficile de modifier une requête POST (cela demande plus d'effort que d'éditer la chaîne de requête). Edit: en d'autres termes, c'est seulement la sécurité par l'obscurité, et à peine cela.

1
répondu eyelidlessness 2008-10-13 22:31:30
la source

Je ne vais pas répéter toutes les autres réponses, mais il y a un aspect que je n'ai pas encore vu mentionné - c'est l'histoire de la disparition de données. Je ne sais pas où le trouver, mais...

en gros, il s'agit d'une application web qui mystérieusement tous les soirs a perdu toutes ses données et personne ne savait pourquoi. L'inspection des journaux a révélé plus tard que le site a été trouvé par google ou une autre araignée arbitraire, qui obtiennent heureusement (lu: GOT) tous les liens qu'il a trouvé sur le site - y compris la suppression de cette entrée" et "êtes-vous sûr?" lien.

en fait - une partie de cela a été mentionnée. C'est l'histoire de "ne pas modifier les données sur OBTENIR, mais seulement sur le POST". Les rampeurs suivront avec joie GET, never POST. Même les robots.la txt n'aide pas contre les chenilles qui se conduisent mal.

1
répondu Olaf Kock 2008-10-14 23:19:05
la source

vous devez également être conscient que si vos sites contient un lien vers d'autres sites externes que vous ne contrôlez pas en utilisant GET va mettre ces données dans l'en-tête refeerer sur les sites externes quand ils appuient sur les liens sur votre site. Le transfert des données de connexion par les méthodes GET est donc toujours un gros problème. Depuis cela pourrait exposer les identifiants de connexion pour un accès facile en vérifiant simplement les journaux ou en regardant dans Google analytics (ou similaire).

1
répondu 3cho 2011-01-18 02:05:40
la source

RFC7231:

" Uri sont destinés à être partagés, non garantis, même lorsqu'ils identifient sécuriser les ressources. Les uri sont souvent affichés sur les écrans, modèles lorsqu'une page est imprimée, et stockés dans une variété de signet non protégés listes. Il est donc imprudent d'inclure les renseignements contenus dans une URI qui sont sensibles et personnellement identifiables;, ou un risque de divulgation.

les auteurs de services devraient éviter les formulaires GET - soumission de données sensibles parce que ces données seront placées dans le demande-cible. De nombreux serveurs, mandataires et agents utilisateurs existants se connectent ou afficher la requête-cible à des endroits où elle pourrait être visible tiers. Ces services devraient utiliser la présentation de formulaires postérieurs à la date de publication. plutôt."

ce RFC indique clairement que les données sensibles ne doivent pas être soumises en utilisant GET. En raison de cette remarque, certains réalisateurs ne pourrait pas traiter les données obtenues à partir de la partie requête d'une requête GET avec le même soin. Je travaille moi-même sur un protocole qui assure l'intégrité des données. Selon cette spécification, Je ne devrais pas avoir à garantir l'intégrité des données GET (ce que je vais faire parce que personne n'adhère à ces spécifications)

1
répondu Silver 2015-11-18 17:22:04
la source

comme certains l'ont déjà dit, HTTPS apporte la sécurité.

Cependant, le POST est un peu plus sûr que d'OBTENIR, parce que OBTENIR pourrait être stockée dans l'histoire.

mais encore plus, malheureusement, parfois, l'élection de la poste ou obtenir n'est pas à la hauteur du développeur. Par exemple, un lien hypertexte est toujours envoyé par GET (à moins qu'il ne soit transformé en un formulaire postal utilisant javascript).

1
répondu magallanes 2016-03-05 14:23:05
la source

GET est visible à n'importe qui (même celui sur votre épaule maintenant) et est enregistré sur le cache, donc est moins sûr de l'utilisation de post, btw post sans certaine routine cryptographique n'est pas sûr, pour un peu de sécurité, Vous avez à utiliser SSL (https)

0
répondu kentaromiura 2008-10-13 22:17:48
la source

une des raisons pour lesquelles POST est pire pour la sécurité est que GET est journalisé par défaut, les paramètres et toutes les données sont presque universellement journalisées par votre serveur web.

POST est le en face de , c'est presque universellement pas connecté , conduisant à de très difficile à repérer attaquant de l'activité.

je n'achète pas l'argument "c'est trop gros", c'est pas une raison pour ne pas le journal anything , au moins 1KB, irait un long chemin pour les gens d'identifier les attaquants travaillant loin à un point d'entrée faible jusqu'à ce qu'il pop's, puis POST fait un double dis-service, en permettant à tout HTTP basé back-door passer silencieusement des quantités illimitées de données.

0
répondu RandomNickName42 2017-05-23 15:34:53
la source

la différence est que GET envoie des données ouvertes et POST cachées (dans l'en-tête http).

donc get est mieux pour les données non-sécurisées, comme les chaînes de requête dans Google. Auth-data ne doit jamais être envoyé via GET - so utiliser POST ici. Bien sûr, le thème entier est un peu plus compliqué. Si vous voulez en savoir plus, lisez cet article (en allemand).

0
répondu Daniel 2011-07-22 03:55:52
la source

Récemment une attaque a été publié, qui permet à l'homme dans un milieu de révéler corps de la requête de comprimé requêtes HTTPS. Parce que les en-têtes de requête et les URL ne sont pas compressés par HTTP, les requêtes GET sont mieux sécurisées contre cette attaque particulière.

il existe des modes dans lesquels les requêtes GET sont également vulnérables, SPDY compresse les en-têtes de requête, TLS fournit également une compression optionnelle (rarement utilisée). Dans ces scénarios l'attaque est plus facile à prévenir (les vendeurs de navigateur ont déjà fourni des correctifs). La compression au niveau HTTP est une fonctionnalité plus fondamentale, il est peu probable que les vendeurs la désactivent.

c'est juste un exemple qui montre un scénario dans lequel GET est plus sûr que POST, mais je ne pense pas que ce serait une bonne idée de choisir GET over POST de cette raison d'attaque. L'attaque est assez sophistiquée et nécessite des pré-requis non-triviaux (L'attaquant doit être capable de contrôler une partie de la demande de contenu). Il est préférable de désactiver la compression HTTP dans les cas où l'attaque serait nuisible.

0
répondu Jan Wrobel 2013-08-02 19:47:21
la source

C'est un vieux post, mais je voudrais l'objet de certaines réponses. Si vous transférez des données sensibles, vous devrez utiliser SSL. Si vous utilisez SSL avec un paramètre GET (par exemple ?userid=123), que les données seront envoyées en texte brut! Si vous envoyez en utilisant un POST, les valeurs sont mises dans le corps crypté du message, et ne sont donc pas lisibles pour la plupart des attaques MITM.

la grande distinction est où les données sont passées. Il n'a de sens que si les données sont placé dans une URL, il ne peut pas être crypté sinon vous ne seriez pas en mesure de router vers le serveur parce que vous seul pouvez lire L'URL. Voilà comment un OBTENIR œuvres.

en bref, vous pouvez transmettre en toute sécurité des données dans un poste sur SSL, mais vous ne pouvez pas le faire avec un GET, en utilisant SSL ou non.

-3
répondu LVM 2012-02-02 21:23:14
la source

même POST accepte les requêtes GET. Supposons que vous avez un formulaire avec des entrées comme user.nom et utilisateur.passwd, ceux qui sont censés soutenir le nom d'utilisateur et mot de passe. Si nous ajoutons un ?de l'utilisateur.name="mon utilisateur et l'utilisateur.passwd= "mon mot de passe", alors la requête sera acceptée en "contournant la page de connexion".

une solution pour cela est d'implémenter des filtres (filtres java en tant que e) du côté du serveur et de détecter qu'aucune chaîne de caractères n'est transmise en tant qu'arguments GET.

-3
répondu Saber Chebka 2012-10-19 11:21:57
la source

Autres questions sur html http security