GET ou POST sont-ils plus sûrs l'un que l'autre ?

Question

Si l'on compare un HTTP GET à un HTTP POST, quelles sont les différences du point de vue de la sécurité ? L'un des choix est-il intrinsèquement plus sûr que l'autre ? Si oui, pourquoi ?

Je me rends compte que POST n'expose pas les informations sur l'URL, mais cela a-t-il une réelle valeur ou est-ce simplement une sécurité par l'obscurité ? Y a-t-il une raison pour laquelle je devrais préférer POST lorsque la sécurité est une préoccupation ?

Editar:
Avec le protocole HTTPS, les données POST sont codées, mais les URL peuvent-elles être reniflées par une tierce partie ? En outre, je travaille avec JSP ; lorsque j'utilise 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 le GET et d'utiliser le code côté serveur pour traiter les informations sensibles à la place ?

Answer 1

La requête GET est marginalement moins sûre que la requête POST. Aucune des deux n'offre une véritable "sécurité" en soi ; l'utilisation de requêtes POST ne sera pas Par magie, la sécurité de votre site Web contre les attaques malveillantes sera considérablement améliorée. Cependant, l'utilisation de requêtes GET puede rendre une application autrement sûre peu sûre.

Le mantra selon lequel vous "ne devez pas utiliser les requêtes GET pour effectuer des modifications" est toujours d'actualité, mais cela n'a pas grand-chose à voir avec les éléments suivants malveillant comportement. Les formulaires de connexion sont les plus susceptibles d'être envoyés en utilisant le mauvais type de demande.

Araignées de recherche et accélérateurs web

C'est la véritable raison pour laquelle vous devez utiliser les requêtes POST pour modifier les données. Les robots de recherche suivront tous les liens de votre site Web, mais ne soumettront pas les formulaires qu'ils trouvent au hasard.

Les accélérateurs Web sont pires que les araignées de recherche, car ils fonctionnent sur la machine du client et "cliquent" sur tous les liens. dans le contexte de l'utilisateur connecté . Ainsi, une application qui utilise une requête GET pour supprimer des éléments, même si cela nécessite un administrateur, obéira volontiers aux ordres de l'accélérateur web (non malveillant !) et de l'administrateur. supprimer tout ce qu'il voit .

Attaque d'un député confus

A attaque du député confus (où le député est le navigateur) est possible, que vous utilisiez une requête GET ou POST. .

Sur les sites web contrôlés par des attaquants, GET et POST sont tout aussi facile à soumettre sans interaction avec l'utilisateur .

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

On pourrait arguer que les accélérateurs web sont un exemple d'attaque adjointe confuse, mais c'est juste une question de définition. En fait, un attaquant malveillant n'a aucun contrôle sur ce type d'attaque. attaque même si le député es confus.

Journaux proxy

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

C'est un argument très faible en faveur du TDP. 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, les paramètres de la requête sont d'une utilité limitée pour un attaquant : ce dont il a réellement besoin, ce sont les cookies, et si la seule chose dont il dispose sont les journaux du proxy, il est peu probable qu'il puisse attaquer une URL GET ou POST.

Il y a une exception pour les demandes de connexion : celles-ci contiennent généralement le mot de passe de l'utilisateur. L'enregistrement de ce mot de passe dans le journal du proxy ouvre un vecteur d'attaque qui est absent dans le cas du POST. Cependant, la connexion via HTTP est de toute façon peu sûre par nature.

Cache du proxy

Les mandataires 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 non cachables avec moins d'efforts que la conversion de l'URL en un gestionnaire POST.

HTTP "Referer"

Si l'utilisateur navigue vers un site web tiers à partir de la page servie en réponse à une demande GET, ce site web tiers peut voir tous les paramètres de la demande GET.

Appartient à la catégorie "révèle les paramètres de la demande à un tiers", dont la gravité dépend de ce qui est présent dans ces paramètres. Les requêtes POST sont naturellement à l'abri, mais pour exploiter la requête GET, un pirate devrait 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 leurs paramètres. L'attaquant peut facilement les obtenir s'il a un accès physique à la machine.

Action de rafraîchissement du navigateur

Le navigateur réessaie une requête GET dès que l'utilisateur appuie sur "rafraîchir". Il peut le faire lors de la restauration des onglets après une fermeture. Toute action (disons, un paiement) sera donc répétée sans avertissement.

Le navigateur ne réessayera pas une demande POST sans avertissement.

C'est une bonne raison pour n'utiliser que des requêtes POST pour modifier des données, mais cela n'a rien à voir avec un comportement malveillant et, par conséquent, avec la sécurité.

Alors, que dois-je faire ?

• Utilisez uniquement des requêtes POST pour modifier les données, principalement pour des raisons non liées à la sécurité.
• N'utilisez que des requêtes POST pour les formulaires de connexion ; le contraire introduit des vecteurs d'attaque.
• Si votre site effectue des opérations sensibles, vous avez vraiment besoin de quelqu'un qui sait ce qu'il fait, car cela ne peut pas être couvert par une seule réponse. Vous devez utiliser HTTPS, HSTS, CSP, atténuer l'injection SQL, Injection de script (XSS) , CSRF et des milliards d'autres choses qui peuvent être spécifiques à votre plate-forme (comme la vulnérabilité de l'affectation de masse dans divers frameworks) : ASP.NET MVC , Ruby on Rails etc.). Il n'existe aucun élément unique qui fera la différence entre "sûr" (non exploitable) et "non sûr".

---

Avec le protocole HTTPS, les données POST sont codées, mais les URL peuvent-elles être reniflées par une tierce partie ?

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

Serait-il juste de dire que la meilleure pratique consiste à éviter de placer des données sensibles dans le POST ou le GET et à utiliser du code côté serveur pour traiter les informations sensibles ?

Cela dépend de sa sensibilité ou, plus précisément, de la manière dont elle l'est. Il est évident que le client le verra. Toute personne ayant un accès physique à l'ordinateur du client le verra. Le client peut le falsifier lorsqu'il vous le renvoie. Si ces éléments sont importants, alors oui, gardez les données sensibles sur le serveur et ne les laissez pas sortir.

Answer 2

En ce qui concerne la sécurité, elles sont intrinsèquement les mêmes. S'il est vrai que POST n'expose pas d'informations via l'URL, il en expose tout autant qu'un GET dans la communication réseau réelle entre le client et le serveur. Si vous devez transmettre des informations sensibles, votre première ligne de défense serait de les transmettre en utilisant Secure HTTP.

Les messages GET ou query string sont très utiles pour les informations nécessaires à la mise en signet d'un élément particulier, ou pour aider à l'optimisation et à l'indexation des éléments par les moteurs de recherche.

Le POST convient aux formulaires standard utilisés pour soumettre des données ponctuelles. Je n'utiliserais pas GET pour afficher des formulaires réels, sauf peut-être dans un formulaire de recherche où vous voulez permettre à l'utilisateur de sauvegarder la requête dans un signet, ou quelque chose de ce genre.

Answer 3

Le fait que les variables soient envoyées par HTTP POST ne vous apporte pas plus de sécurité que les variables envoyées par HTTP GET.

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

• OPTIONS
• GET
• TETE
• POST
• PUT
• DELETE
• TRACE
• CONNECTER

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 ceci :

 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

Maintenant, supposons que nous ayons 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 :

• Non crypté
• Inclus dans les deux exemples
• Ils peuvent faire l'objet d'une surveillance et sont sujets à des attaques MITM.
• Facilement reproductible par des tiers et des robots script.

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

Beaucoup de Navigateurs Les comportements stockent l'adresse de la page, mais cela ne signifie pas que vous pouvez ignorer ces autres problèmes.

Donc, pour être précis :

L'un est-il intrinsèquement plus sûr que l'autre ? Je me rends compte que POST n'expose pas les informations sur l'URL, mais cela a-t-il une réelle valeur ou est-ce simplement une sécurité par l'obscurité ? Quelle est la meilleure pratique en la matière ?

C'est correct, parce que le logiciel que vous utilisez pour parler HTTP a tendance à stocker les variables de la requête avec une méthode mais pas une autre ne fait qu'empêcher quelqu'un de regarder l'historique de votre navigateur ou une autre attaque naïve d'un enfant de 10 ans qui pense comprendre le h4x0r1ng, ou des scripts qui vérifient votre magasin d'historique. Si vous avez un scripts qui peut vérifier votre historique, vous pourriez tout aussi bien en avoir un qui vérifie votre trafic réseau, donc toute cette sécurité par l'obscurité ne fournit de l'obscurité qu'aux enfants scripts et aux petites amies jalouses.

Avec https, les données POST sont codées, mais les urls peuvent-elles être reniflées par une tierce partie ?

Voici comment fonctionne le SSL. Vous vous souvenez des deux requêtes que j'ai envoyées ci-dessus ? Voici à quoi elles ressemblent avec SSL : (J'ai changé la page en https://encrypted.google.com/ car exemple.com ne répond pas sur SSL).

POST sur SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$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$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

GET sur SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'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_/&5p@V f $)/xvxfgO'q@y&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 le HEX en ASCII, certains ne sont évidemment pas affichables)

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

Alors laissez-moi faire une grande déclaration audacieuse ici. Votre site Web ne bénéficie pas d'une plus grande sécurité avec une méthode HTTP qu'avec une autre, les pirates et les novices du monde entier savent exactement comment faire ce que je viens de démontrer ici. Si vous voulez de la sécurité, utilisez SSL. Les navigateurs ont tendance à stocker l'historique, il est recommandé par la RFC2616 9.1.1 de ne PAS utiliser GET pour effectuer une action, mais penser que POST fournit la sécurité est tout à fait faux.

La seule chose vers laquelle POST est une mesure de sécurité ? La protection contre votre ex jaloux qui feuillette l'historique de votre navigateur. C'est tout. Le reste du monde est connecté à votre compte et se moque de vous.

Pour mieux démontrer pourquoi POST n'est pas sécurisé, Facebook utilise des requêtes POST partout, alors comment des logiciels tels que Mouton de feu existent ?

Notez que vous pouvez être attaqué avec CSRF même si vous utilisez HTTPS et que votre site ne contient pas XSS vulnérabilités. En résumé, ce scénario d'attaque suppose que la victime (l'utilisateur de votre site ou service) est déjà connectée et dispose d'un cookie approprié, puis que son navigateur est invité à effectuer une action sur votre site (supposé sécurisé). Si vous n'avez pas de protection contre CSRF, l'attaquant peut toujours exécuter des actions avec les informations d'identification de la victime. L'attaquant ne peut pas voir la réponse du serveur car elle est transférée au navigateur de la victime, mais les dégâts sont généralement déjà faits à ce stade.

Answer 4

Il n'y a pas de sécurité supplémentaire.

Les données postales n'apparaissent pas dans l'historique et/ou les fichiers journaux, mais si les données doivent être sécurisées, vous avez besoin de SSL.
Sinon, quiconque renifle le fil peut lire vos données de toute façon.

Answer 5

Même si POST n'offre aucun avantage réel en matière de sécurité par rapport à GET Pour les formulaires de connexion ou tout autre formulaire contenant des informations relativement sensibles, assurez-vous d'utiliser la méthode suivante POST comme :

1. L'information POST ed ne sera pas enregistré dans l'historique de l'utilisateur.
2. Les informations sensibles (mot de passe, etc.) envoyées dans le formulaire ne seront pas visibles par la suite dans la barre d'URL (en utilisant GET il sera visible dans l'historique et la barre d'URL).

Aussi, GET a une limite théorique de données. POST ne le fait pas.

Pour les informations réellement sensibles, veillez à utiliser SSL ( HTTPS )