Est-ce que GET ou POST est plus sécurisé 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 les informations sur l'URL, mais y a-t-il une valeur réelle à cela ou s'agit-il simplement d'une sécurité par l'obscurité? Existe-t-il une raison pour laquelle je devrais préférer POST lorsque la sécurité est un problème?
Edit:
Sur HTTPS, POST les données sont codées, mais les URL pourraient-elles être reniflées par un tiers? De plus, je traite avec JSP; En utilisant JSP ou un cadre similaire, serait-il juste de dire que la meilleure pratique consiste à éviter de placer des données sensibles dans le POST ou GET et à utiliser un code côté serveur pour gérer des informations sensibles?
En ce qui concerne la sécurité, ils sont fondamentalement les mêmes. S'il est vrai que POST n'expose pas les 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 publications GET ou de chaîne de requête sont vraiment utiles pour les informations nécessaires pour mettre en favori 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 poster des formulaires réels, sauf peut-être dans un formulaire de recherche dans lequel vous souhaitez autoriser l'utilisateur à 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; utiliser POST demandes ne rendra pas comme par magie votre site Web protégé contre les attaques malveillantes d'un montant notable. Cependant, l'utilisation de requêtes GET peut rendre une application par ailleurs sécurisée et non sécurisée.
Le mantra selon lequel "vous ne devez pas utiliser les requêtes GET pour apporter des modifications" est toujours valable, mais cela n'a pas grand-chose à voir avec le comportement malveillant . Les formulaires de connexion sont les plus sensibles aux envois utilisant un type de demande incorrect.
Araignées de recherche et accélérateurs Web
C’est la véritable raison pour laquelle vous devez utiliser POST demandes de modification de données. Les araignées de recherche suivront chaque lien sur votre site Web, mais ne soumettront pas de formulaires aléatoires qu’elles trouveront.
Les accélérateurs Web sont pires que les robots 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 elle nécessite un administrateur, obéira avec joie aux ordres de l'accélérateur Web (non malveillant!) Et supprimera tout ce qu'elle voit .
Attaque confuse
Une attaque confuse de député (où le député est le navigateur) est possible que vous utilisiez une requête GET ou une demande POST .
Sur les sites Web contrôlés par des attaquants, GET et POST sont également faciles à soumettresans interaction de l'utilisateur .
Le seul scénario dans lequel 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 d'images arbitraires (permettant à l'attaquant d'injecter un GET arbitraire demande), mais empêche toutes les manières d’injecter une demande POST arbitraire, automatique ou manuelle.
On pourrait soutenir que les accélérateurs Web sont un exemple d’attaque confuse par un adjoint, mais c’est juste une question de définition. En tout état de cause, un attaquant malveillant n’a aucun contrôle sur cela. Il ne s’agit donc guère d’une attaque , même si le suppléant est confus.
Journaux de proxy
Les serveurs proxy sont susceptibles de consigner les URL GET dans leur intégralité, sans effacer la chaîne de requête. Les paramètres de demande POST ne sont pas normalement consigné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 a déjà tout ce dont il a besoin. Deuxièmement, les paramètres de requête ont une utilité limitée pour un attaquant: ce dont ils ont vraiment besoin, ce sont les cookies. Par conséquent, s’ils ne disposent que de journaux de proxy, ils ne seront probablement pas en mesure d’attaquer GET ou POST URL.
Il existe une exception pour les demandes de connexion: elles ont tendance à contenir le mot de passe de l’utilisateur. L'enregistrer dans le journal du proxy ouvre un vecteur d'attaque absent dans le cas du POST. Cependant, la connexion via HTTP pur est intrinsèquement non sécurisée.
Cache proxy
La mise en cache des mandataires 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 de convertir l'URL en un gestionnaire POST.
HTTP "Référent"
Si l'utilisateur devait accéder à un site Web tiers à partir de la page servie en réponse à une demande GET, ce site Web tiers aurait accès à 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êtesPOST sont naturellement immunisées contre cette éventualité. Toutefois, pour exploiter la requête GET, un pirate informatique 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 "journaux de proxy": les demandes GET sont stockées dans l'historique du navigateur avec leurs paramètres. L’attaquant peut facilement les obtenir s’il dispose d’un accès physique à la machine.
Action d'actualisation du navigateur
Le navigateur réessayera une demande GET dès que l'utilisateur clique sur "Actualiser". Cela peut être le cas 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 de n’utiliser que POST demandes de modification de données, mais n’a rien à voir avec un comportement malveillant et, partant, avec la sécurité.
Donc qu'est ce que je devrais faire?
- Utilisez uniquement POST demandes de modification de données, principalement pour des raisons non liées à la sécurité.
- Utilisez uniquement POST demandes de 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, injection de script (XSS) , CSRF et un nombre considérable d’autres éléments pouvant être spécifiques à votre environnement. 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 fera la différence entre "sécurisé" (non exploitable) et "non sécurisé".
Sur HTTPS, les données POST sont codées, mais des URL pourraient-elles être reniflées par une tierce partie?
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 GET et à utiliser un code côté serveur pour gérer des informations sensibles?
Cela 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 verra. Le client peut l'usurper en le renvoyant. Si oui, conservez les données sensibles sur le serveur et ne les laissez pas partir.
Vous ne bénéficiez pas d'une plus grande sécurité car les variables sont envoyées via HTTP POST que vous ne le faites avec des variables envoyées via HTTP GET.
HTTP/1.1 nous fournit un tas de méthodes pour envoyer une requête :
- LES OPTIONS
- GET
- HEAD
- POST
- METTRE
- EFFACER
- TRACE
- RELIER
Supposons que vous ayez le document HTML suivant 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
Supposons maintenant que nous avons changé cette méthode de demande en 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 analysé et soumis aux attaques MITM.
- Facilement reproduit 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 des navigateurs stockent l'adresse de la page, mais cela ne signifie pas que vous pouvez ignorer l'un de ces autres problèmes.
Donc, pour être précis:
Est-ce que l'un est intrinsèquement plus sûr qu'un autre? Je me rends compte que POST n'expose pas les informations sur l'URL, mais y a-t-il une valeur réelle à cela ou s'agit-il simplement d'une 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. Cela empêche uniquement de consulter l’historique de votre navigateur ou toute autre attaque naïve d’un enfant de 10 ans qui pense comprendre l’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 également en avoir un qui vérifie votre trafic réseau. Ainsi, toute la sécurité à travers l’obscurité ne fournit que de l’obscurité aux enfants et aux copines jalouses.
Sur https, POST les données sont codées, mais les URL peuvent-elles être reniflées par un tiers?
Voici comment fonctionne SSL. Rappelez-vous ces deux demandes que j'ai envoyées ci-dessus? Voici à quoi ils ressemblent en 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
OBTENIR 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 doivent évidemment pas être affichables)
Toute la conversation HTTP est cryptée, la seule partie visible de la communication se trouvant sur la couche TCP/IP (adresse IP et informations sur le 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’une autre, les pirates informatiques et les utilisateurs de logiciels informatiques du monde entier savent exactement comment faire ce que je viens de démontrer ici. Si vous voulez la sécurité, utilisez SSL. Les navigateurs ont tendance à stocker l'historique. Dans la RFC2616 9.1.1, il est recommandé de NE PAS utiliser GET pour effectuer une action, mais de penser que POST fournit une sécurité totalement fausse.
La seule chose à laquelle POST est une mesure de sécurité? Protection contre votre ex jaloux en feuilletant l'historique de votre navigateur. C'est ça. Le reste du monde est connecté à votre compte en riant de vous.
Pour démontrer plus en détail pourquoi POST n'est pas sécurisé, Facebook utilise des requêtes POST partout dans le monde. Comment des logiciels tels que FireSheep peuvent-ils 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 possède un cookie approprié, puis que le navigateur de la victime est invité à faire quelque chose avec votre site (supposé sécurisé). Si vous ne disposez 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 celle-ci sera transférée sur le navigateur de la victime, mais les dégâts sont généralement déjà causés à ce moment-là.
Il n'y a pas de sécurité supplémentaire.
Les données de publication n'apparaissent pas dans l'historique ni dans les fichiers journaux, mais si les données doivent être sécurisées, vous avez besoin de SSL.
Sinon, quiconque renifle le fil peut quand même lire vos données.
Même si POST ne présente aucun avantage réel en termes de sécurité par rapport à GET, pour les formulaires de connexion ou tout autre formulaire comportant des informations relativement sensibles, assurez-vous que vous utilisez POST en tant que:
- Les informations
POSTed ne seront pas enregistrées dans l'historique de l'utilisateur. - 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).
De plus, GET a une limite théorique de données. POST ne le fait pas.
Pour de vraies informations sensibles, veillez à utiliser SSL (HTTPS)
Ni GET, ni POST ne sont intrinsèquement "plus sûrs" que les autres, 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 les requêtes idempotentes tandis que POST est plus approprié pour les requêtes "d'action", mais vous pouvez vous tirer une balle dans le pied tout aussi facilement si vous ne le faites pas. Ne comprenez pas l’architecture de sécurité de l’application que vous gérez.
Il est probablement préférable de lire Chapitre 9: Définitions de méthodes de HTTP/1.1 RFC pour avoir une idée générale de ce que GET et POST ont été initialement envisagés. pas méchant.
La différence entre GET et POST ne doit pas être considérée en termes de sécurité, mais plutôt dans les intentions du serveur. GET ne doit jamais modifier les données sur le serveur, du moins que dans les journaux, mais POST peut créer de nouvelles ressources.
Les proxys sympas ne mettront pas en cache les données POST, mais ils peuvent mettre en cache les données GET à partir 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 jouaient 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 commettent aucune modification, telle que la suppression de lignes de base de données, etc.
Ce n'est pas lié à la sécurité mais ... les navigateurs ne mettent pas en cache POST requêtes.
Ma méthodologie habituelle pour choisir est quelque chose comme:
- GET pour les éléments qui seront récupérés plus tard par URL
- Par exemple. La recherche devrait être GET afin que vous puissiez faire search.php? S = XXX plus tard
- POST pour les éléments qui seront envoyé
- Ceci est relativement invisible avec GET et plus difficile à envoyer, mais les données peuvent toujours être envoyées via cURL.
Comme par magie, aucune des deux ne confère la sécurité à une demande. Toutefois, GET implique certains effets secondaires qui l’empêchent généralement d’être sécurisée.
Les URL GET apparaissent dans l'historique du navigateur et dans les journaux du serveur Web. Pour cette raison, ils ne doivent jamais être utilisés pour des éléments tels que les formulaires de connexion et les numéros de carte de crédit.
Cependant, la simple publication de ces données ne les sécurise pas non plus. Pour cela, vous voulez SSL. GET et POST _ envoient des données en texte clair sur le fil lorsqu'elles sont utilisées sur HTTP.
Il y a d'autres bonnes raisons pour POST données, comme la possibilité de soumettre des quantités illimitées de données ou de masquer des paramètres à des 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 peu scrupuleuse accepte les requêtes GET telles que:
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 la 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 vraies API fonctionnent de cette façon.
Je ne voudrais 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 chose. Utilisez chaque cas échéant.
SECURITE en tant que sécurité des données EN TRANSIT: pas de différence entre POST et GET.
SECURITY en tant que sécurité des données SUR L'ORDINATEUR: POST est plus sûr (pas d'historique d'URL)
La notion de sécurité n'a de sens que si vous définissez ce pour quoi vous voulez être sécurisé.
Si vous souhaitez être protégé contre l'historique du navigateur stocké, certains types de journalisation et les personnes consultant vos URL, alors POST est plus sécurisé.
Si vous souhaitez protéger votre réseau contre les activités de votre réseau, il n'y a aucune différence.
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 de la référence sur les sites externes lorsqu'ils appuieront sur les liens de votre site. Donc, le transfert des données de connexion via les méthodes GET est TOUJOURS un gros problème. Dans la mesure où cela pourrait exposer les informations de connexion pour un accès facile, il suffit de consulter les journaux ou de consulter Google Analytics (ou similaire).
Il est plus difficile de modifier une requête POST (elle nécessite plus d'effort 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 ça.
De nombreuses personnes adoptent une convention (à laquelle Ross fait allusion) selon laquelle les requêtes GET récupèrent uniquement les données et ne modifient aucune donnée sur le serveur. Les requêtes POST sont utilisées pour toutes les modifications de données. Bien que l’un ne soit pas intrinsèquement sûr que l’autre, si vous respectez cette convention, vous pouvez appliquer une logique de sécurité transversale (par exemple, uniquement les personnes possédant un compte). peut modifier les données, ainsi les POST non authentifiés sont rejetés).
Comme certaines personnes l’ont déjà dit, le protocole 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 de GET n’incombe pas au développeur. Par exemple, un lien hypertexte est toujours envoyé par GET (sauf s’il est transformé en un formulaire via javascript).
Je ne suis pas sur le point de 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 données en train de disparaître. Je ne sais pas où le trouver, mais ...
En gros, il s’agit d’une application Web qui, chaque nuit, perdait mystérieusement toutes ses données et personne ne savait pourquoi. L'inspection des journaux a révélé par la suite que le site avait été trouvé par Google ou un autre araignée arbitraire, qui récupérait avec bonheur (lire: GOT) tous les liens trouvés sur le site, y compris les "supprimer cette entrée" et "êtes-vous sûr?" liens.
En fait, une partie de cela a été mentionnée. Ceci 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 le fichier robots.txt ne résout pas le problème des robots mal conduits.
RFC7231:
"Les adresses URI sont destinées à être partagées et non sécurisées, même lorsqu'elles identifient des ressources sécurisées. Les adresses URI sont souvent affichées à l'écran, ajoutées aux modèles lorsqu'une page est imprimée et stockées dans une variété de listes de signets non protégés. Il est donc déconseillé d'inclure informations contenues dans une adresse URI qui sont sensibles, personnellement identifiables ou qui présentent un risque de divulgation.
Les auteurs de services doivent éviter les formulaires GET 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 d'utilisateurs existants enregistrent ou affichent la cible de la demande à des emplacements où elle pourrait être visible par des tiers. De tels services devraient utiliser plutôt la soumission de formulaire basée sur POST. "
Ce 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 risquent de ne pas gérer 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 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 n'adhère à ces spécifications)
GET est visible par tout le monde (même celui qui se trouve sur votre épaule) et est enregistré dans le cache. Par conséquent, il est moins sûr d'utiliser post, btw post sans routine de chiffrement incertaine, pour un peu de sécurité, vous devez utiliser SSL ( https)
Récemment ne attaque a été publiée, ce qui permet à un homme du milieu de révéler le corps de la requête de requêtes HTTPS compressées. Étant donné 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 des requêtes, TLS fournit également une compression optionnelle (rarement utilisée). Dans ces scénarios, l'attaque est plus facile à empêcher (les éditeurs de navigateurs ont déjà fourni des correctifs). La compression de niveau HTTP est une fonctionnalité plus fondamentale, il est peu probable que les fournisseurs la désactivent.
Il s'agit simplement d'un exemple montrant 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 sur POST pour cette raison de l'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 requête). Il est préférable de désactiver la compression HTTP dans les scénarios où l'attaque serait nuisible.
Une raison 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 opposé , il est presque universellement non enregistré , conduisant à très difficile à repérer l'activité de l'attaquant.
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, aiderait beaucoup les gens à identifier les attaquants qui travaillent loin un point d’entrée faible jusqu’à ce qu’il apparaisse, puis POST effectue un double dédoublement, en permettant à toute solution back-door basée sur HTTP de transmettre en silence des quantités illimitées de données.
Déni de responsabilité: Les points suivants ne s'appliquent qu'aux appels d'API et non aux URL du site Web.
Sécurité sur le résea: 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 Les appels d'API JS etc. sont des appels AJAX passés par front- fin. Celles-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: Avec l'utilisation du format d'écriture du masquage des données et des journaux d'accès, il est possible de masquer toutes ou seulement les données sensibles de l'URL de la demande.
Visibilité des données dans la console du navigateur: Pour quelqu'un d'intention malicieuse, les mêmes efforts sont presque nécessaires pour afficher POST les données autant que GET.
Par conséquent, avec les pratiques de journalisation correctes, l'API GET est aussi sécurisée que l'API POST. Suivant POST partout, force la définition d'API médiocre et doit être évité.
La différence est que GET envoie les données ouvertes et POST cachées (dans l'en-tête http).
Donc, mieux vaut obtenir des données non sécurisées, telles que les chaînes de requête dans Google. Les données d'authentification ne doivent jamais être envoyées via GET - utilisez donc 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).