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

Lorsque vous comparez 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 d'informations sur l'URL, mais y a-t-il une réelle valeur ou s'agit-il simplement de sécurité par l'obscurité? Y a-t-il une raison pour laquelle je devrais préférer le POST lorsque la sécurité est un problème?

Modifier:
via HTTPS, les données POST sont codées, mais les URL peuvent-elles être reniflées par un tiers? De plus, je traite avec JSP; lors de l'utilisation de JSP ou d'un framework 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 gérer les informations sensibles à la place?

En ce qui concerne la sécurité, ils sont intrinsèquement les mêmes. S'il est vrai que POST n'expose pas d'informations via l'URL, il expose autant d'informations 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 à l'aide de HTTP sécurisé.

Les messages GET ou de chaîne de requête sont vraiment bons pour les informations nécessaires à la mise en signet d'un élément particulier, ou pour aider à l'optimisation des moteurs de recherche et à l'indexation des éléments.

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

La demande GET est légèrement moins sécurisée que la demande POST. Aucun des deux n'offre une véritable «sécurité» en soi; l'utilisation de requêtes POST ne sécurisera pas comme par magie votre site Web contre les attaques malveillantes. Cependant, l'utilisation de requêtes GET peut rendre une application autrement sécurisée non sécurisée.

Le mantra selon lequel "vous ne devez pas utiliser les requêtes GET pour apporter des modifications" est toujours très valable, mais cela n'a pas grand-chose à voir avec les programmes malveillants comportement . Les formulaires de connexion sont les plus sensibles à l'envoi en utilisant le mauvais type de demande.

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

C'est la vraie raison pour laquelle vous devez utiliser les requêtes POST pour modifier les données. Les araignées de recherche suivront tous les liens de 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, car ils s'exécutent 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 elle nécessite un administrateur, obéira volontiers aux ordres de l'accélérateur Web (non malveillant!) Et supprimera tout ce qu'il voit .

Attaque d'un adjoint confus

Une attaque de député confuse (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 également faciles à soumettre sans interaction de 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 (disons, un forum tiers) permettent d'incorporer des images arbitraires (permettant à l'attaquant d'injecter une demande GET arbitraire), mais empêchent tout les moyens d'injecter une requête POST arbitraire, qu'elle soit automatique ou manuelle.

On pourrait soutenir que les accélérateurs Web sont un exemple d'attaque adjointe confuse, mais ce n'est qu'une question de définition. Si quelque chose, un attaquant malveillant n'a aucun contrôle sur cela, il ne s'agit donc pas d'une attaque , même si le député est confus.

Journaux proxy

Les serveurs proxy sont susceptibles de consigner les URL GET dans leur intégralité, sans supprimer la chaîne de requête. Les paramètres de requête 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 de POST. Premièrement, le trafic non chiffré peut être enregistré dans son intégralité; un proxy malveillant possède déjà tout ce dont il a besoin. Deuxièmement, les paramètres de demande sont d'une utilité limitée pour un attaquant: ce dont ils ont vraiment besoin, ce sont les cookies, donc si la seule chose dont ils disposent sont des journaux de proxy, il est peu probable qu'ils puissent attaquer une URL GET ou POST.

Il existe une exception pour les demandes de connexion: celles-ci contiennent généralement le mot de passe de l'utilisateur. L'enregistrement dans le journal proxy ouvre un vecteur d'attaque absent dans le cas de POST. Cependant, la connexion via HTTP standard est de toute façon intrinsèquement non sécurisée.

Cache proxy

La mise en cache des proxys peut 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'effort que la conversion de l'URL en un gestionnaire POST.

HTTP "Referer"

Si l'utilisateur devait naviguer vers un site Web tiers à partir de la page servie en réponse à une demande GET, ce site Web tiers verrait tous les paramètres de la demande GET.

Appartient à la catégorie «révèle les paramètres de 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 de cela, mais pour exploiter la requête GET, un pirate informatique 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 d'actualisation du navigateur

Le navigateur va réessayer une requête GET dès que l'utilisateur frappe "Actualiser". Cela 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 réessayera pas une demande POST sans avertissement.

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

Donc qu'est ce que je devrais faire?

• Utilisez uniquement les demandes POST pour modifier les données, principalement pour des raisons non liées à la sécurité.
• Utilisez uniquement les demandes POST pour les formulaires de connexion; faire autrement introduit des vecteurs d'attaque.
• Si votre site effectue des opérations sensibles, vous avez vraiment besoin de quelqu'un qui sache 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, l'injection de script (XSS) , CSRF et une multitude d'autres choses qui peuvent être spécifiques à votre plate-forme (comme la vulnérabilité d'affectation de masse dans divers cadres: ASP.NET MVC , Ruby on Rails , etc.). Il n'y a pas une seule chose qui fera la différence entre "sécurisé" (non exploitable) et "non sécurisé".

Sur HTTPS, les données POST sont encodées, mais les URL 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 consiste à éviter de placer des données sensibles dans le POST ou le GET et d'utiliser à la place du code côté serveur pour gérer les informations sensibles?

Cela dépend de sa sensibilité, ou plus précisément de quelle manière. De toute évidence, le client le verra. Toute personne disposant d'un accès physique à l'ordinateur du client le verra. Le client peut l'usurper en vous le renvoyant. Si cela importe, oui, conservez les données sensibles sur le serveur et ne les laissez pas partir.

Vous ne disposez pas d'une plus grande sécurité, car les variables sont envoyées via HTTP POST que vous n'en avez avec les variables envoyées via HTTP GET.

HTTP / 1.1 nous fournit un tas de méthodes pour envoyer une demande :

• OPTIONS
• AVOIR
• TÊTE
• PUBLIER
• METTRE
• SUPPRIMER
• TRACE
• RELIER

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

Imaginons maintenant que nous avons changé cette méthode de demande 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
• Peut être évité et sujet à des attaques MITM.
• Reproduit facilement par des tiers et des robots de script.

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

De nombreux comportements de navigateurs 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 qu'un autre? Je me rends compte que POST n'expose pas d'informations sur l'URL, mais y a-t-il une réelle valeur ou s'agit-il uniquement de sécurité par l'obscurité? Quelle est la meilleure pratique ici?

C'est correct, car le logiciel que vous utilisez pour parler HTTP a tendance à stocker les variables de demande avec une méthode mais pas une autre empêche seulement quelqu'un de consulter 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 script qui peut vérifier votre magasin d'historique, vous pouvez 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 script kiddies et aux jalouses copines.

Sur https, les données POST sont encodées, mais les URL peuvent-elles être reniflées par un tiers?

Voici comment SSL fonctionne. Rappelez-vous ces deux demandes que j'ai envoyées ci-dessus? Voici à quoi ils ressemblent dans SSL: (J'ai changé la page en https://encrypted.google.com/ car example.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

OBTENEZ 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 devraient évidemment pas être affichables)

La conversation HTTP entière 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 sur le port de connexion).

Permettez-moi donc de faire une grande déclaration audacieuse ici. Votre site Web ne bénéficie pas d'une plus grande sécurité sur une méthode HTTP que sur une autre, les pirates et les internautes 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 carrément faux.

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

Pour démontrer davantage pourquoi POST n'est pas sécurisé, Facebook utilise les 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 HTTPS et que votre site ne contient pas de vulnérabilités XSS . En bref, 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 le navigateur de la victime est invité à faire quelque chose avec 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 des victimes. L'attaquant ne peut pas voir la réponse du serveur car elle sera transférée vers le navigateur de la victime, mais le dommage est généralement déjà fait à ce stade.

Il n'y a aucune sécurité supplémentaire.

Les données de publication 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, toute personne qui renifle le fil peut lire vos données de toute façon.

Même si cela POSTn'apporte aucun avantage réel en matière de sécurité par rapport GETaux formulaires de connexion ou tout autre formulaire contenant des informations relativement sensibles, assurez-vous que vous utilisez en POSTtant que:

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

A également GETune limite théorique de données.POSTnon.

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

Ni l'un ni l'autre de GET et POST n'est intrinsèquement "plus sûr" que l'autre, tout comme aucun des télécopieurs et des téléphones n'est "plus sûr" que l'autre. Les différentes méthodes HTTP sont fournies afin que vous puissiez choisir celle qui convient le mieux au problème que vous essayez de résoudre. GET est plus approprié pour idempotent requêtes tandis que POST est plus approprié pour les requêtes "action", mais vous pouvez vous tirer dans le pied tout aussi facilement avec n'importe laquelle d'entre elles si vous ne comprenez pas l'architecture de sécurité de l'application que vous gérez.

Il est probablement préférable de lire le Chapitre 9: Définitions des méthodes de la RFC HTTP / 1.1 pour avoir une idée globale de ce que GET et POST étaient initialement envisagés.

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 doit jamais modifier les données sur le serveur - du moins dans les journaux - mais POST peut créer de nouvelles ressources.

Les bons mandataires ne mettront pas en cache les données POST, mais ils peuvent mettre en cache les données GET de l'URL, vous pouvez donc dire que POST est censé être plus sécurisé. Mais les données POST seraient toujours disponibles pour les mandataires qui ne jouent 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 n'engagent aucune modification, comme la suppression de lignes de base de données, etc.

Ma méthodologie habituelle pour choisir est quelque chose comme:

• OBTENEZ des éléments qui seront récupérés ultérieurement par URL
  • Par exemple, la recherche devrait être GET afin que vous puissiez faire search.php? S = XXX plus tard
• POST pour les articles qui seront envoyés
  • C'est relativement invisible comparé à GET et plus difficile à envoyer, mais les données peuvent toujours être envoyées via cURL.

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

Aucun des deux ne confère comme par magie la sécurité à une demande, mais GET implique certains effets secondaires qui l'empêchent généralement d'être sécurisé.

Les URL GET apparaissent dans l'historique du navigateur et les journaux du serveur Web. Pour cette raison, ils ne doivent 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 les rend pas non plus sécurisées. Pour cela, vous voulez SSL. GET et POST envoient des données en texte clair sur le câble lorsqu'ils sont utilisés sur HTTP.

Il existe également d'autres bonnes raisons pour les données POST - comme la possibilité de soumettre des quantités illimitées de données ou de masquer les paramètres aux utilisateurs occasionnels.

L'inconvénient est que les utilisateurs ne peuvent pas mettre en signet les résultats d'une requête envoyée via POST. Pour cela, vous avez besoin de GET.

Considérez cette situation: Une API bâclé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 / un avertissement concernant la demande, toute cette ligne est enregistrée dans le fichier journal. Pire encore: si vous oubliez de désactiver les messages d'erreur sur le serveur de production, ces informations sont simplement affichées en clair dans le navigateur! Maintenant, vous venez de donner votre clé API à tout le monde.

Malheureusement, de véritables API fonctionnent de cette façon.

Je n'aimerais pas l'idée d'avoir des informations sensibles dans les journaux ou de les afficher dans le navigateur. POST et GET ne sont pas les mêmes. Utilisez-les le cas échéant.

1. LA SÉCURITÉ comme sécurité des données EN TRANSIT: pas de différence entre POST et GET.

2. LA SÉCURITÉ comme sécurité des données SUR L'ORDINATEUR: POST est plus sûr (pas d'historique URL)

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

Si vous souhaitez être protégé contre l'historique du navigateur stocké, certains types de journalisation et les personnes qui consultent vos URL, alors POST est plus sécurisé.

Si vous voulez vous protéger contre quelqu'un qui renifle votre activité réseau, il n'y a aucune différence.

De nombreuses personnes adoptent une convention (mentionnée par Ross) selon laquelle les requêtes GET ne récupèrent que les 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' on est pas plus sûr en soi que l'autre, si vous ne suivez cette convention, vous pouvez appliquer une logique de sécurité transversale (par exemple les personnes seules avec des comptes peuvent modifier les données, si POSTs non authentifiées sont rejetées).

Il est plus difficile de modifier une requête POST (cela nécessite plus d'efforts que la modification de la chaîne de requête). Edit: En d'autres termes, ce n'est que la sécurité par l'obscurité, et à peine cela.

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 des données. Je ne sais pas où le trouver, mais ...

Fondamentalement, il s'agit d'une application Web qui mystérieusement perdait toutes ses nuits 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 a heureusement OBTENU (lire: OBTENU) tous les liens qu'il a trouvés sur le site - y compris "supprimer cette entrée" et "êtes-vous sûr?" liens.

En fait - une partie de cela a été mentionnée. C'est l'histoire derrière "ne changez pas les données sur GET mais seulement sur POST". Les robots suivront avec plaisir GET, jamais POST. Même robots.txt n'aide pas contre les robots qui se comportent mal.

Vous devez également savoir que si vos sites contiennent des liens vers d'autres sites externes que vous ne contrôlez pas à l'aide de GET, ces données seront placées dans l'en-tête du référent sur les sites externes lorsqu'ils appuient sur les liens de votre site. Le transfert des données de connexion via les méthodes GET est donc TOUJOURS un gros problème. Étant donné que cela pourrait exposer les informations de connexion pour un accès facile en vérifiant simplement les journaux ou en consultant Google Analytics (ou similaire).

RFC7231:

"Les URI sont destinés à être partagés et non sécurisés, même lorsqu'ils identifient des ressources sécurisées. Les URI sont souvent affichés sur les écrans, ajoutés aux modèles lorsqu'une page est imprimée et stockés dans une variété de listes de signets non protégés. Il n'est donc pas judicieux d'inclure des informations au sein d'un URI qui sont sensibles, personnellement identifiables ou présentent un risque de divulgation.

Les auteurs de services devraient éviter les formulaires basés sur l'EEG pour la soumission de données sensibles, car ces données seront placées dans la cible de la demande. De nombreux serveurs, mandataires et agents utilisateurs existants enregistrent ou affichent la cible de demande dans des endroits où elle peut être visible par des tiers. Ces services devraient plutôt utiliser la soumission de formulaires basée sur POST. "

Cette RFC indique clairement que les données sensibles ne doivent pas être soumises à l'aide de GET. En raison de cette remarque, certains implémenteurs peuvent ne pas gérer les données obtenues à partir de la partie requête d'une demande GET avec le même soin. Je travaille moi-même sur un protocole qui garantit 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 ferai car personne ne respecte ces spécifications)

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

Cependant, POST est un peu plus sûr que GET car GET pourrait être stocké dans l'historique.

Mais plus encore, malheureusement, parfois, l'élection de POST ou GET n'est pas du ressort du développeur. Par exemple, un lien hypertexte est toujours envoyé par GET (à moins qu'il ne soit transformé en un formulaire de publication à l'aide de javascript).

GET est visible par tout le monde (même celui sur votre épaule maintenant) et est enregistré dans le cache, il est donc moins sûr d'utiliser post, btw post sans une certaine routine de cryptographie n'est pas sûr, pour un peu de sécurité, vous devez utiliser SSL ( https)

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

POST est le contraire , il n'est presque pas journalisé , ce qui entraîne une activité d'attaquant très difficile à repérer.

Je n'achète pas l'argument "c'est trop gros", ce n'est pas une raison pour ne pas enregistrer quoi que ce soit , au moins 1 Ko, cela aiderait beaucoup les gens à identifier les attaquants travaillant à un point d'entrée faible jusqu'à ce qu'il apparaisse, alors POST le fait un double service, en permettant à toute porte dérobée basée sur HTTP de transmettre silencieusement des quantités illimitées de données.

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

Donc, mieux vaut pour les données non sécurisées, comme les chaînes de requête dans Google. Les données d'authentification ne seront jamais envoyées via GET - utilisez donc POST ici. Bien sûr, tout le thème est un peu plus compliqué. Si vous voulez en savoir plus, lisez cet article (en allemand).

Récemment, une attaque a été publiée, qui permet à un homme au milieu de révéler un corps de demande de demandes HTTPS compressées. Étant donné que les en-têtes de demande et l'URL ne sont pas compressés par HTTP, les demandes GET sont mieux protégé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 facultative (rarement utilisée). Dans ces scénarios, l'attaque est plus facile à empêcher (les fournisseurs de navigateurs ont déjà fourni des correctifs). La compression au niveau HTTP est une fonctionnalité plus fondamentale, il est peu probable que les fournisseurs la désactivent.

C'est juste un exemple qui montre un scénario dans lequel GET est plus sécurisé que POST, mais je ne pense pas que ce serait une bonne idée de choisir GET plutôt que POST pour cette raison d'attaque. L'attaque est assez sophistiquée et nécessite des conditions préalables non triviales (l'attaquant doit pouvoir contrôler une partie du contenu de la demande). Il est préférable de désactiver la compression HTTP dans les scénarios où l'attaque serait nuisible.

Avis de non-responsabilité: les points suivants ne s'appliquent qu'aux appels d'API et non aux URL de site Web.

Sécurité sur le réseau : vous devez utiliser HTTPS. GET et POST sont également sûrs dans ce cas.

Historique du navigateur : pour les applications frontales telles que Angular JS, React JS, etc., les appels API sont des appels AJAX effectués par le front-end. Ceux-ci ne font pas partie de l'historique du navigateur. Par conséquent, POST et GET sont également sécurisés.

Journaux côté serveur : en utilisant un ensemble d'écriture de masquage des données et le format des journaux d'accès, il est possible de masquer toutes ou seulement les données sensibles de l'URL de demande.

Visibilité des données dans la console du navigateur: pour quelqu'un qui a une intention malicieuse, ce sont presque les mêmes efforts pour afficher les données POST autant que GET.

Par conséquent, avec de bonnes pratiques de journalisation, l'API GET est aussi sécurisée que l'API POST. Suivre POST partout, force les mauvaises définitions d'API et doit être évité.

La publication est la plus sécurisée avec SSL installée car elle est transmise dans le corps du message.

Mais toutes ces méthodes ne sont pas sécurisées car le protocole 7 bits qu'il utilise en dessous est piratable avec échappement. Même à travers un pare-feu d'application Web de niveau 4.

Les prises ne sont pas non plus garanties ... Même si c'est plus sûr à certains égards.

Ceci est un ancien message, mais je voudrais m'opposer à certaines des réponses. Si vous transférez des données sensibles, vous voudrez utiliser SSL. Si vous utilisez SSL avec un paramètre GET (par exemple? Userid = 123), ces données seront envoyées en texte brut! Si vous envoyez à l'aide d'un POST, les valeurs sont placées dans le corps chiffré du message et ne sont donc pas lisibles par la plupart des attaques MITM.

La grande distinction est l'endroit où les données sont transmises. Il est logique que si les données sont placées dans une URL, elles NE PEUVENT PAS être chiffrées sinon vous ne pourrez pas les acheminer vers le serveur car vous seul pouvez lire l'URL. Voilà comment fonctionne un GET.

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

Même POST accepte les requêtes GET. Supposons que vous ayez un formulaire ayant des entrées comme user.name et user.passwd, celles-ci sont censées prendre en charge le nom d'utilisateur et le mot de passe. Si nous ajoutons simplement un? User.name = "mon utilisateur & user.passwd =" mon mot de passe ", alors la demande sera acceptée en" contournant la page de connexion ".

Une solution pour cela consiste à implémenter des filtres (filtres java comme e) côté serveur et à détecter qu'aucune requête de chaîne n'est transmise en tant qu'arguments GET.