TL; DR: HTTPS fournit le chiffrement, et c'est la seule chose qui protège les paramètres.

Il est bien connu que les requêtes GET avec des arguments? xx = yy incorporés peuvent être modifiés en transit, et ne sont donc pas sécurisés.

Si vous n'utilisez pas de cryptage, tout n'est pas sécurisé: HTTP, Telnet, FTP, TFTP, IRC, SNMP, SMTP, IMAP, POP3 , DNS, Gopher ...

Si je change la requête en POST ...

... cela ne change rien du tout.

et utilisez HTTPS ...

HTTPS change tout.

Toute requête HTTP non protégée par TLS n'est pas protégée. Peu importe si vous utilisez GET, POST, PUT, s'il s'agit d'un en-tête personnalisé, rien ne change rien.

Par exemple, il s'agit d'une requête GET:

  GET / test? field1 = value1&field2 = value2 HTTP / 1.1Host: foo.examAccept: text / html  

Et ceci est une requête POST:

  POST / test HTTP / 1.1Host: foo.exampleContent-Type: application / x-www-form-urlencodedContent-Length: 27field1 = value1&field2 = value2  

Quelle est la différence? Sur la requête GET, les paramètres sont sur la première ligne et sur le POST, les paramètres sont sur la dernière ligne. Juste ça. Les raisons techniques derrière GET ou POST ne sont pas le point ici.

Supposons que des paramètres de style GET aient été ajoutés à une requête POST - ces paramètres seraient-ils ignorés de manière fiable?

Cela dépend entièrement de l'application. Sur PHP, par exemple, si l'application attend $ username = $ _POST ['username'] , l'envoyer en tant que paramètre GET ne change rien du tout, car l'application obtiendra le paramètre POST.

Qu'en est-il d'une sorte d'attaque de rétrogradation de sécurité? Si le manipulateur d'URL force l'échec des transactions HTTPS, puis le client / serveur rétrograde "utilement" vers HTTP, ce qui permettrait de manipuler le corps POST non chiffré.

Pas facile pour les serveurs correctement configurés. S'ils utilisent l'en-tête HTTP Strict Transport Security, cela oblige le client à accéder uniquement au site en utilisant HTTPS, même si l'utilisateur force HTTP et le port 80. Le navigateur mettra à jour utilement vers HTTPS, pas l'inverse.

Même sur les serveurs qui n'utilisent pas les en-têtes HSTS, si le premier accès se fait via HTTPS, il n'est pas anodin de revenir à HTTP. L'attaquant doit envoyer un faux certificat et le client doit accepter le faux certificat pour qu'une connexion HTTPS soit redirigée vers HTTP. Mais si l'attaquant réussit, il continuera généralement à utiliser HTTPS car le client a déjà accepté son faux certificat de toute façon.

Non, non, non.

HTTPS protège l'ensemble de la requête HTTP. Le chemin de l'url, les paramètres, les cookies, les en-têtes http, le corps ... La seule chose qu'il ne protège pas (à part les paramètres tcp comme les adresses IP et les ports) est le nom d'hôte auquel vous vous connectez, qui est divulgué via le SNI extension (cela devrait être corrigé par tls-esni, juste un brouillon pour l'instant)

En tant que tel, lors de l'utilisation de HTTPS, l'envoi de paramètres "sensibles" (tels que l'utilisateur et le mot de passe ou compte bancaire à facturer) dans GET n'est pas non sécurisé car un attaquant pourrait le modifier.

(et s'il n'utilise pas HTTPS, c'est une mauvaise idée même avec POST)

Cependant, il n'en reste pas moins problématique.

• Les paramètres GET font partie de l'url, et apparaissent dans les logs du serveur, l'historique de votre navigateur, l'analyse du site, l'impression de la page, une analyse antivirus de la page ...
• Les requêtes GET sont définies comme étant idempotentes . Le fait de réessayer une demande GET (même automatiquement) n'aura pas d'effets secondaires. Vous pouvez imaginer ce qui pourrait arriver si la requête signifiait "veuillez transférer ce montant sur le compte ###"
• D'un autre côté, POST n'a pas ce comportement. Vous aurez sûrement remarqué que votre navigateur vous avertit avant de renvoyer une requête POST, avertissant des actions déclenchées par cela qui pourrait se reproduire.
• Avoir certains paramètres via GET pourrait aider avec les attaques de fixation de session (comme le chargement d'un url vous connectant avec l'utilisateur et le mot de passe de l'attaquant, avant de facturer "votre" crédit en ligne)
• En général, il est beaucoup plus facile de faire charger une page avec certains paramètres que via POST (toujours possible en utilisant javascript, cependant, utilisez des jetons anti-XSS).

Supposons que des paramètres de style GET aient été ajoutés à une requête POST - ces paramètres seraient-ils ignorés de manière fiable?

Cela dépend du site Web. Ils peuvent accepter certains paramètres uniquement en tant que GET et d'autres uniquement en tant que POST, mais également certains en tant que GET ou POST. Si le paramètre a avec le même nom est fourni dans les deux sens, ils choisiront probablement le paramètre POST, mais il pourrait être configuré pour utiliser GET, ou erreur également.

Qu'en est-il d'une sorte d'attaque de déclassement de sécurité? Si le manipulateur d'URL force l'échec des transactions HTTPS, puis le client / serveur rétrograde "utilement" vers HTTP, ce qui permettrait de manipuler le corps POST non chiffré.

Un client qui a automatiquement rétrogradé une requête HTTPS vers HTTP (qui, comme vous le constatez, peut facilement être effectuée par un attaquant sur le réseau) est complète et totalement interrompue . Veuillez déposer une CVE pour cela.

Il est bien connu que les requêtes GET avec des arguments? xx = yy incorporés peuvent être modifiées en transit, et ne sont donc pas sécurisées.

Il s'agit généralement d'une référence à des situations où GET les demandes sont enregistrées dans les journaux d'historique, y compris le navigateur local et éventuellement les logiciels d'inspection de contenu ou les proxys. Sinon, il n'y a pas de différence fonctionnelle de sécurité entre l'utilisation des requêtes HTTP GET et POST via TLS.

Deux autres cas me concernent. Supposons que des paramètres de style GET aient été ajoutés à une requête POST - ces paramètres seraient-ils ignorés de manière fiable?

Dépend entièrement du code de votre application.

Qu'en est-il d'une sorte d'attaque de déclassement de sécurité? Si le manipulateur d'URL force l'échec des transactions HTTPS, puis le client / serveur rétrograde "utilement" vers HTTP, ce qui permettrait de manipuler le corps POST non chiffré.

Vous pouvez vous en occuper sous HTTP en utilisant Strict Transport Security (HSTS) éventuellement avec préchargement . Cela demande aux navigateurs de refuser d'accéder à un site donné en HTTP ... dans un certain délai. Et il y a une demande initiale qui, sauf si vous utilisez préchargement , le navigateur doit apprendre que HSTS est activé.

Si vous voyez l'URL dans le navigateur, cela ne signifie pas que l'URL est envoyée sur le réseau sous une telle forme. En cas de HTTPS, un attaquant ne peut voir que l'hôte cible et le port de votre requête. L'attaquant ne peut rien voir de plus comme la méthode, l'URL, les en-têtes, le corps.

Si vous utilisez HTTPS, vos données ne peuvent pas être modifiées sur le chemin vers l'hôte et le port de destination. Cela vaut également pour l'URL: elle n'est visible par personne et ne peut pas être manipulée.

L'URL n'est visible que côté serveur, une fois que le serveur a déchiffré votre requête.

Avec HTTPS, l'intégralité de la requête HTTP passe par le canal SSL crypté, de sorte que les paramètres GET et POST, ainsi que le chemin de l'URL, les cookies et toutes les autres parties de la requête sont protégés contre la falsification MitM en transit.

Cela ne peut garantir que le serveur et le client sont sans compromis, mais cela signifie que vous n'avez pas à faire confiance à chaque ordinateur aléatoire entre les deux.

Le nom d'hôte et le numéro de port sont observables par a MitM, mais ils ne peuvent pas être falsifiés, sauf en tuant la connexion.

Les horaires de trafic et les tailles (remplies) sont observables, et ces informations pourraient être utilisées par un observateur motivé pour déduire ce qui est transféré. Par exemple, un gros fichier peut être une vidéo, ou une taille de fichier spécifique correspond à un fichier spécifique.

Les systèmes ne retournent pas automatiquement à HTTP si HTTPS échoue; ce serait catastrophique. Sans SSL, rien du tout n'est protégé contre l'enregistrement total et / ou la modification.

D'autres réponses étant bonnes concernant SSL (il s'appelle TLS de nos jours, mais qu'importe), elles ont presque contourné

Supposons que des paramètres de style GET aient été ajoutés à une requête POST - ces paramètres seraient-ils ignoré de manière fiable?

Non. Il existe même des frameworks d'application qui permettent un mélange gratuit entre l'URL et les paramètres du corps de la requête dans une requête POST.

En JavaEE, par exemple, il faut faire un travail supplémentaire pour déterminer si un paramètre spécifié est venu à partir de l'URL ou du corps de la requête. Et généralement, personne ne s'en soucie.

Cela n'a pas non plus d'importance du point de vue de la sécurité - quiconque peut transmettre un paramètre d'URL au serveur peut également transmettre un paramètre de corps de requête. Si la connexion n'est pas chiffrée, un homme du milieu peut la modifier comme il l'entend.

Si la connexion est chiffrée avec SSL / TLS, elle est chiffrée dans son ensemble, avant que toute interaction HTTP puisse avoir lieu et il reste chiffré jusqu'à ce qu'il soit fermé.

La seule chose qu'un homme du milieu peut faire pour une connexion correctement chiffrée est de la rompre. (Eh bien, on peut aussi exploiter certaines vulnérabilités de protocole ou d'implémentation, mais elles sont rares de nos jours)

En plus des autres réponses, il y a une autre dimension de sécurité à considérer, et c'est à voir avec ce qui arrive à l'URL. Aucun des éléments suivants ne permet d'intercepter ou de modifier les valeurs, indiquez simplement où elles pourraient être lues . Tous ces éléments s'appliquent également à HTTP et HTTPS; la présence de HTTPS n'atténue aucun d'entre eux.

1. Même en utilisant HTTPS, l'URL complète est transmise à tous les serveurs tiers qui chargent des composants sur la page via le référent en-tête. Cela signifie que tous les paramètres GET pourraient être exposés à des tiers. Cela peut être atténué en définissant une Politique de référence sur votre demande.

2. Les serveurs Web enregistrent généralement les requêtes HTTP dans le système de fichiers. Par défaut, ceux-ci sont configurés pour consigner l'URL qui a été envoyée au serveur, ce qui signifie que tous les paramètres GET peuvent être visibles dans vos journaux et disponibles pour quiconque y a accès. Certains serveurs proxy enregistrent également les URL qui ont été visitées (mais le fait qu'un serveur proxy puisse voir votre trafic chiffré est un autre niveau de confiance).

3. Votre navigateur peut mettre en cache un liste des URL que vous avez visitées, qui incluraient également les paramètres GET.