Frage:
SSL mit GET und POST
TomJ
2012-03-09 01:17:55 UTC
view on stackexchange narkive permalink

Ich bin ziemlich neu in der Sicherheit, also verzeihen Sie meine grundlegende Frage, aber verschlüsselt SSL POST-Anforderungen, aber keine GET-Anforderungen?

Zum Beispiel, wenn ich zwei Anforderungen habe

GET: www.mycoolsite.com/index? Id = 1&type = xyz

POST

Website: www.mycoolsite.com/index{Params: id = 1&type = xyz}

Ist es sicher anzunehmen, dass jemand die gesamte GET-Anforderung abfangen kann (Lese-ID und Typ), aber wenn er den POST abfängt, kann er den Site-Pfad sehen, aber weil er über SSL läuft können sie die Parameter von id und type nicht sehen?

Nein, die vollständige _HTTP_-Kommunikation ist in _SSL / TLS_ gekapselt, ** wenn das Protokoll für beide Beispiele _HTTPS_ ist! ** Beachten Sie, dass referenzierte Ressourcen _ (Bilder usw.) _ abhängig von ihrer URL möglicherweise unsicher bereitgestellt werden.
Ich wollte nur darauf hinweisen, dass bei Verwendung von GETs zum Übergeben von Anmeldeinformationen (unabhängig davon, ob Sie SSL verwenden) die Kennwörter in den Webserverprotokollen im Klartext gespeichert werden.
Sechs antworten:
#1
+60
user2213
2012-03-09 01:45:59 UTC
view on stackexchange narkive permalink

Nun ist die Frage, wissen Sie, wie eine HTTP-Anfrage aussieht ?

Nun, wenn Sie dies nicht tun, hier ein Beispiel für eine:

  GET / test? param1 = hello&param2 = world HTTP / 1.1Host: subdomain.test.comBenutzer-Agent: Mozilla / 5.0 (X11; Linux x86_64; rv: 10.0.1) Gecko / 20100101 Firefox / 10.0.1Accept: image / png, image / *; q = 0,8, * / *; q = 0,5Accept-Sprache: en-gb, en; q = 0,5Accept-Codierung: gzip, deflateDNT: 1Verbindung: Keep-Alive  

Alle dieser Informationen sind im SSL-Transport enthalten - wie der Kommentar zu Ihrer Antwort freundlich sagt. Dies bedeutet:

  • Get-Parameter werden verschlüsselt.
  • HTTP-Body (Post-Parameter) werden verschlüsselt.

Was ist nicht unbedingt sicher:

  • Der Host, nach dem Sie fragen. Die meisten Webserver unterstützen heutzutage Host: etwas -Parameter, sodass mehrere Domänen von einem Webserver auf einer Schnittstelle und einer IP-Adresse verwaltet werden können. Dieser Header ist eindeutig verschlüsselt. Wenn Sie jedoch Nicht-https-Datenverkehr zur Site ausführen, sollte klar sein, mit welchen Hosts Sie möglicherweise eine Verbindung herstellen. Auch wenn dies nicht der Fall ist, sagt Ihnen Reverse DNS mit Sicherheit, was auf dieser IP gehostet wird, und Sie können von dort aus wahrscheinlich eine vernünftige Vermutung anstellen.
  • Ihre Browser- / Client-Informationen. Leider ist jeder https-Client anders und sein Verhandlungsprozess kann möglicherweise verraten, auf welcher Plattform er ausgeführt wird oder welcher Browser er ist. Dies ist keineswegs das Ende der Welt, es ist nur eine Tatsache zu verstehen.

POST-Anfragen sehen ähnlich aus wie Anfragen, außer dass sie einen Text enthalten. Dies kann folgendermaßen aussehen:

  POST / testpost HTTP / 1.1Host: subdomain.test.com Benutzer-Agent: Mozilla / 5.0 (X11; Linux x86_64; rv: 10.0.1) Gecko / 20100101 Firefox / 10.0.1Accept: image / png, image / *; q = 0,8, * / *; q = 0,5Accept-Sprache: en-gb, en; q = 0,5Accept-Encoding: gzip, deflateDNT: 1Connection: keep- livingparam1 = hello&param2 = hallo  

Es gibt natürlich einige kompliziertere Varianten, aber im Grunde ist alles sowieso verschlüsselt.

Alle Antworten hier waren sehr gut. Tatsächlich war es schwierig, die "beste" Antwort zu finden, da sich beide gegenseitig ergänzten. Der Grund, warum ich mich für dieses entschieden habe, ist, dass es gezeigt hat, wie ein Get and Post aussieht. Ich mag es jedoch sehr, dass Gilles andere Dinge beachtet hat, und das gilt auch für Dr. Jimbobs Antwort. Tatsächlich war Ordags Kommentar etwas, über das ich vorher nicht einmal nachgedacht habe, deshalb bin ich auch dafür dankbar. Wenn ich könnte, würde ich alle Antworten zusammenfassen und alle als akzeptierte Antwort markieren, da jede auf der letzten aufbaut.
Um ein Detail hinzuzufügen, macht der Browser den Zielhost über die Erweiterung [Server Name Indication (SNI)] (http://en.wikipedia.org/wiki/Server_Name_Indication) von TLS sichtbar.
#2
+36
dr jimbob
2012-03-09 02:08:07 UTC
view on stackexchange narkive permalink

Ich habe dies in den anderen Antworten nicht erwähnt, aber Sie sollten im Allgemeinen keine geheimen Informationen (Passwörter) in GET-Anforderungen einfügen, auch nicht mit SSL, sondern stattdessen POST verwenden. Warum? Die URL mit den vertraulichen Informationen wird im Allgemeinen an beiden Enden protokolliert. B. in der Verlaufsliste Ihres Browsers (https://www.example.com?user=me&password=MyPassword) sowie in den Protokollen auf dem Server. POST-Informationen (insbesondere mit Kennwörtern) werden im Allgemeinen nicht in Webserver-Protokolle geschrieben, können jedoch offensichtlich so konfiguriert werden, dass sie protokolliert werden. Daher ist es am besten, Kennwörter an verschiedenen Standorten nicht wiederzuverwenden (oder zu verwenden).

Diese [Antwort erwähnt, dass der Referer möglicherweise vertrauliche Informationen enthält] (http://stackoverflow.com/a/26672275/819887). In diesem [newsthead] (http://answers.google.com/answers/threadview/id/758002.html#comments) wird angegeben, dass vertrauliche Informationen entfernt werden. Das lässt mich verwirrt; Könnte der Referer vertrauliche Informationen enthalten? Ist dies auch bei einer Get-Anfrage von Javascript mit Ajax in einer einseitigen Anwendung noch der Fall?
@threeFourOneSixOneThree - Es ist für Websites möglich, vertrauliche Informationen über Javascript zu entfernen. Standardmäßig (zumindest bei allen von mir getesteten Browsern) enthält der Referer-Header jedoch alle HTTP-GET-Abfrageparameter. Ich habe auf reddit einen Link zu whatismyreferer.com erstellt (der die Verweisinformationen wiedergibt, die Websites normalerweise protokollieren). Gehen Sie zu diesem Link mit den GET-Parametern am Ende wie: https://www.reddit.com/r/sandboxtest/comments/2l7adf/referer_test/?username=dumb&password=leaked und Sie werden feststellen, dass die sensiblen Teile Teil des Referers sind Header (auch mit https).
#3
+21
Gilles 'SO- stop being evil'
2012-03-09 01:48:52 UTC
view on stackexchange narkive permalink

SSL verschlüsselt und stellt die Authentizität der gesamten Verbindung sicher, einschließlich der angeforderten Methode und URL. Ein GET ist genauso gut geschützt wie ein POST.

Wenn SSL wie beabsichtigt funktioniert, kann ein Lauscher nur sehen, welche IP-Adresse mit welcher IP-Adresse verbunden ist (und an welchem ​​Port, aber normalerweise 443). zu welcher Zeit und wie viel. Wenn sich mehrere virtuelle Hosts auf demselben Computer befinden, kann der Angreifer nicht wissen, welchen Sie kontaktieren (der Lauscher kann jedoch Ihre DNS-Anforderungen unmittelbar vor der HTTPS-Anforderung sehen und eine plausible Vermutung anstellen). Alle diese Informationen werden auch authentifiziert: Ein aktiver Angreifer kann nicht Man-in-the-Middle spielen und die Daten während der Übertragung ändern.

Dinge, die dazu führen können, dass SSL nicht wie beabsichtigt funktioniert:

  • Anwendungsmissbrauch, bei dem einige Daten versehentlich über einfaches HTTP gesendet werden.
  • Eine der seltenen Sicherheitsanfälligkeiten im SSL-Protokoll, z. B. die kürzlich aufgetretene BEAST-Sicherheitsanfälligkeit.
  • Beachten Sie in diesem Zusammenhang, dass SSL, da es die meiste Zeit verwendet wird, den Server authentifiziert, nicht jedoch den Client. Der Server kann nichts über den Client annehmen.
  • Ein Seitenkanalangriff kann dem Lauscher einige Informationen preisgeben. Zum Beispiel kann der genaue Zeitpunkt, zu dem die Teilnehmer Daten senden, etwas darüber aussagen, wie die Daten berechnet werden und somit über die Art der Daten. Die Größe jedes Pakets ist dem Angreifer ebenfalls bekannt. Wie aufschlussreich dies sein kann, hängt davon ab, ob die Teilnehmer Vorsichtsmaßnahmen treffen und von der Art der Informationen. Ein Gespräch in Echtzeit ist für eine solche Verkehrsanalyse viel anfälliger als das Herunterladen einer Datei.
  • Siehe auch Wie ist es möglich, dass Personen, die beobachten, dass eine HTTPS-Verbindung hergestellt wird, nicht wissen, wie sie entschlüsselt werden sollen? für einige Hintergrundinformationen.

    #4
    +6
    AviD
    2012-03-15 16:16:21 UTC
    view on stackexchange narkive permalink

    Nur um noch ein kleines Detail hinzuzufügen, wie dies über HTTP erreicht wird.
    Sie fragen sich wahrscheinlich (oder sollten es sein, wenn Sie wissen, dass Sie mit dem SSL-Handshake vertraut sind ), wie der SSL-Kanal erstellt wird, ohne dass die GET-Anforderung unverschlüsselt gesendet wird? Was ist, wenn meine Anfrage über einen Proxy erfolgen muss - wie ist das möglich?

    HTTP v1.1 führte eine CONNECT HTTP-Methode ein, die im Grunde genommen eine vereinfachte Anforderung über einen Proxy an den Server sendet, der nur die einfachste Host-URL enthält (ohne zusätzliche Parameter, Header oder Körper). Basierend auf dieser Anforderung wird ein SSL-Tunnel erstellt und anschließend die ursprüngliche GET- (oder POST-) Anforderung darüber gesendet.

    #5
    +4
    goodguys_activate
    2012-03-15 20:18:54 UTC
    view on stackexchange narkive permalink

    Quelle: Antwort auf Stapelüberlauf

    Die GET-Methode ist nur zum Abrufen von Daten und vorgesehen sollte keine Nebenwirkungen haben. POST ist jedoch für diesen speziellen Zweck gedacht: Ändern von Daten auf der Serverseite.

    Auf GET-Anforderungen kann problemlos verzichtet werden (siehe Fälschung von standortübergreifenden Anforderungen ) Das einfache Platzieren eines Bildes auf einer Seite beim Fälschen von POST-Anforderungen ist nicht so einfach (dies ist auch ein Grund, warum Sie nur autorisierte POST-Anforderungen zulassen sollten).

    #6
    +4
    Rodney
    2014-01-16 21:34:03 UTC
    view on stackexchange narkive permalink

    Ein weiterer Punkt, der nicht erwähnt wird, ist, dass bei Verwendung von GET und eingebetteten oder verknüpften Inhalten von Drittanbietern (z. B. Website-Anzeigen) diese Website von Drittanbietern die vollständige URL (mit vertraulichen Parameterdaten) im Referer-Header erhält.

    Dadurch werden die Daten Dritten zugänglich gemacht, die sie nicht haben sollten.



    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...