web-dev-qa-db-fra.com

SSL avec GET et POST

Je suis assez nouveau en matière de sécurité, alors pardonnez ma question de base, mais SSL crypte-t-il les demandes POST mais pas GET?

Par exemple, si j'ai deux demandes

OBTENEZ: www.mycoolsite.com/index?id=1&type=xyz

POST

site: www.mycoolsite.com/index {Paramètres: id = 1 & type = xyz}

Est-il sûr de supposer que quelqu'un est capable d'intercepter toute la demande GET (lecture de l'identifiant et du type), mais s'il intercepte le POST, il pourra voir le chemin du site, mais parce qu'il va sur SSL, ils ne peuvent pas voir les paramètres d'id et de type?

tlsrest
58
TomJ

Maintenant, la question est, savez-vous à quoi ressemble une requête HTTP ?

Eh bien, en supposant que non, voici un exemple:

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

Toutes toutes ces informations sont encapsulées dans le transport SSL - comme le dit gentiment le commentaire sur votre réponse. Ça signifie:

  • Les paramètres d'obtention sont chiffrés.
  • Le corps HTTP (paramètres de publication) est crypté.

Ce qui n'est pas forcément sécurisé:

  • L'hôte que vous demandez. De nos jours, la plupart des serveurs Web prennent en charge Host: something paramètres afin que plusieurs domaines puissent être gérés par un serveur Web sur une interface et une adresse IP. De toute évidence, cet en-tête est crypté, cependant, si vous exécutez du trafic non https vers le site, il doit être clair à quels hôtes vous pouvez vous connecter. Même si ce n'est pas le cas, le DNS inversé vous dira certainement ce qui est hébergé sur cette IP et vous pouvez probablement faire une estimation raisonnable à partir de là.
  • Votre navigateur/informations client. Malheureusement, chaque client https est différent et son processus de négociation peut potentiellement révéler sur quelle plate-forme il s'exécute ou quel navigateur il est. Ce n'est pas du tout la fin du monde, c'est juste un fait à comprendre.

Les requêtes POST se ressemblent pour obtenir des requêtes, sauf qu'elles contiennent un corps. Cela peut ressembler à ceci:

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

Il y a bien sûr des variantes plus compliquées, mais essentiellement elles sont toutes cryptées de toute façon.

59
user2213

Je n'ai pas vu cela mentionné dans les autres réponses, mais vous ne devriez généralement pas mettre d'informations secrètes (mots de passe) dans les requêtes GET même avec SSL, mais utilisez plutôt POST à la place. Pourquoi? L'URL avec le les informations sensibles seront généralement enregistrées aux deux extrémités; par exemple, dans la liste de l'historique de votre navigateur (https://www.example.com?user=me&password=MyPassword) ainsi que les journaux sur le serveur. POST les informations (en particulier avec les mots de passe) ne sont généralement pas écrites dans les journaux du serveur Web, bien qu'elles puissent évidemment être configurées pour être enregistrées - il est donc préférable de ne pas réutiliser (ou utiliser des mots de passe similaires) sur différents sites.

36
dr jimbob

SSL crypte et garantit l'authenticité de toute la connexion, y compris la méthode et l'URL demandées. Un GET est tout aussi bien protégé qu'un POST.

Lorsque SSL fonctionne comme prévu, un espion ne peut voir que quelle adresse IP se connecte à quelle adresse IP (et sur quel port, mais c'est généralement 443), à quelle heure et combien. S'il y a plusieurs hôtes virtuels sur la même machine, l'attaquant ne peut pas savoir lequel vous contactez (cependant, l'écouteur peut voir vos requêtes DNS juste avant la requête HTTPS et faire une supposition plausible). Toutes ces informations sont également authentifiées: un attaquant actif ne peut pas jouer man-in-the-middle et modifier les données en transit.

Choses qui peuvent empêcher SSL de fonctionner comme prévu:

  • Utilisation abusive de l'application, où certaines données sont accidentellement envoyées via HTTP simple.
  • L'une des rares vulnérabilités du protocole SSL, comme la récente vulnérabilité BEAST .
  • Mauvaise manipulation de certificat, qui permet à l'attaquant de se faire passer pour le serveur, soit parce que le certificat du serveur a été divulgué, une autorité de certification a incorrectement remis un certificat à l'attaquant, soit parce que le client ne vérifie pas correctement le certificat du serveur.
    • Sur cette note, n'oubliez pas que SSL, tel qu'il est utilisé la plupart du temps, authentifie le serveur mais pas le client. Le serveur ne peut rien supposer du client.
  • Un attaque par canal latéral peut révéler certaines informations à l'écouteur. Par exemple, le moment exact auquel les participants envoient des données peut révéler quelque chose sur la façon dont les données sont calculées et donc sur la nature des données. L'attaquant connaît également la taille de chaque paquet. La manière dont cela peut être révélateur dépend du fait que les participants prennent des précautions et de la nature des informations. Une conversation en temps réel est beaucoup plus sujette à une telle analyse du trafic que le téléchargement d'un fichier.

Voir aussi Comment est-il possible que des personnes observant une connexion HTTPS en cours d'établissement ne sachent pas comment la décrypter? pour quelques informations.

20
Gilles 'SO- stop being evil'

Juste pour ajouter un petit détail supplémentaire, sur la façon dont cela est accompli via HTTP.
Vous vous demandez probablement (ou vous devriez être, si vous connaissez la prise de contact SSL ), comment le canal SSL est créé, sans que la demande GET soit envoyée non chiffrée? Et si ma demande doit passer par un proxy - comment est-ce possible?

HTTP v1.1 a introduit une CONNECT méthode HTTP, qui envoie essentiellement une requête simplifiée au serveur via un proxy, contenant uniquement l'URL d'hôte la plus simple (sans aucune addition paramètres, en-têtes ou corps). Sur la base de cette demande, un tunnel SSL est construit, puis la demande GET (ou POST) d'origine est envoyée par-dessus.

6
AviD

Un autre point non mentionné est que si vous utilisez GET et que vous avez du contenu tiers intégré ou lié (annonces de site par exemple), ce site tiers obtiendra l'URL complète (avec des données de paramètres sensibles) dans l'en-tête Referer.

Cela expose les données à des tiers qui ne devraient pas les avoir.

4
Rodney

Source: Réponse sur débordement de pile

méthode GET est destiné à la récupération de données uniquement et ne devrait pas avoir d'effets secondaires . Mais POST est destiné à cet usage spécifique: modifier les données côté serveur.

Les requêtes GET peuvent facilement être annulées (voir Falsification de requêtes intersites ) en plaçant simplement une image sur une page tout en forgeant POST ne sont pas si faciles (c'est aussi une raison pour laquelle vous ne devez autoriser que les POST requêtes) autorisées.

4
goodguys_activate