Ist eine HTTPS-Abfragezeichenfolge sicher?

Question

Ich erstelle eine sichere webbasierte API, die HTTPS verwendet. Wenn ich jedoch den Benutzern erlaube, sie zu konfigurieren (einschließlich des Sendens des Kennworts), indem ich eine Abfragezeichenfolge verwende, wird dies auch sicher sein, oder sollte ich erzwingen, dass dies über ein POST geschieht?

Answer 1

Ja, das ist sie. Die Verwendung von GET für sensible Daten ist jedoch eine schlechte Idee. aus mehreren Gründen:

• Meistens HTTP-Referrer-Leck (ein externes Bild auf der Zielseite könnte das Passwort verraten[1])
• Das Passwort wird in den Serverprotokollen gespeichert (was natürlich schlecht ist)
• Verlaufs-Caches in Browsern

Auch wenn Querystring sicher ist, wird daher nicht empfohlen, sensible Daten über Querystring zu übertragen.

[1] Allerdings muss ich anmerken, dass der RFC besagt, dass Browser keine Referrer von HTTPS nach HTTP senden sollten. Das bedeutet jedoch nicht, dass eine schlechte Browser-Symbolleiste eines Drittanbieters oder ein externes Bild/Flash von einer HTTPS-Website nicht durchsickern kann.

Answer 2

Aus der Sicht des "Schnüffelns von Netzwerkpaketen" ist eine GET-Anfrage sicher, da der Browser zunächst die sichere Verbindung herstellt und dann die Anfrage mit den GET-Parametern sendet. Allerdings werden GET-URLs im Browserverlauf / in der Autovervollständigung des Benutzers gespeichert, was kein guter Ort ist, um z. B. Passwortdaten zu speichern. Dies gilt natürlich nur, wenn Sie die umfassendere "Webservice"-Definition verwenden, die den Dienst von einem Browser aus aufrufen kann. Wenn Sie nur von Ihrer benutzerdefinierten Anwendung aus auf den Dienst zugreifen, sollte dies kein Problem darstellen.

Daher sollte die Verwendung von post zumindest für Passwortdialoge bevorzugt werden. Wie in dem von littlegeek geposteten Link erwähnt, wird eine GET-URL mit größerer Wahrscheinlichkeit in die Serverprotokolle geschrieben.

Answer 3

Sí werden Ihre Abfragezeichenfolgen verschlüsselt.

Der Grund dafür ist, dass Abfragezeichenfolgen Teil des HTTP-Protokolls sind, das ein Protokoll der Anwendungsschicht ist, während der Sicherheitsteil (SSL/TLS) von der Transportschicht stammt. Die SSL-Verbindung wird zuerst aufgebaut und dann werden die Abfrageparameter (die zum HTTP-Protokoll gehören) an den Server gesendet.

Beim Aufbau einer SSL-Verbindung führt Ihr Client die folgenden Schritte der Reihe nach aus. Angenommen, Sie versuchen, sich bei einer Website namens Beispiel.com und Ihre Anmeldedaten mit Abfrageparametern senden möchten. Ihre vollständige URL könnte wie folgt aussehen:

https://example.com/login?username=alice&password=12345)

1. Ihr Client (z. B. Browser/Mobile App) löst zunächst Ihren Domänennamen auf example.com zu einer IP-Adresse (124.21.12.31) über eine DNS-Anfrage. Bei der Abfrage dieser Informationen werden nur domänenspezifische Informationen verwendet, d. h. nur example.com verwendet werden.
2. Nun wird Ihr Client versuchen, eine Verbindung zum Server mit der IP-Adresse 124.21.12.31 und versucht, eine Verbindung zu Port 443 herzustellen (SSL-Service-Port, nicht der Standard-HTTP-Port 80).
3. Nun, der Server auf example.com sendet seine Zertifikate an Ihren Client.
4. Ihr Client verifiziert die Zertifikate und beginnt mit dem Austausch eines gemeinsamen geheimen Schlüssels für Ihre Sitzung.
5. Erst nach dem erfolgreichen Aufbau einer sicheren Verbindung werden Ihre Abfrageparameter über die sichere Verbindung gesendet.

Daher werden Sie keine sensiblen Daten preisgeben. Die Übermittlung Ihrer Anmeldedaten über eine HTTPS-Sitzung mit dieser Methode ist jedoch nicht der beste Weg. Sie sollten sich für einen anderen Ansatz entscheiden.

Answer 4

Ja. Der gesamte Text einer HTTPS-Sitzung ist durch SSL gesichert. Das gilt auch für die Abfrage und die Kopfzeilen. In dieser Hinsicht wären ein POST und ein GET genau dasselbe.

Wie sicher Ihre Methode ist, lässt sich ohne genaue Prüfung nicht sagen.

Answer 5

SSL stellt zunächst eine Verbindung zum Host her, so dass der Hostname und die Portnummer als Klartext übertragen werden. Wenn der Host antwortet und die Abfrage erfolgreich war, verschlüsselt der Client die HTTP-Anfrage mit der eigentlichen URL (d. h. alles nach dem dritten Schrägstrich) und sendet sie an den Server.

Es gibt mehrere Möglichkeiten, diese Sicherheit zu umgehen.

Es ist möglich, einen Proxy so zu konfigurieren, dass er als "Mann in der Mitte" fungiert. Im Grunde sendet der Browser die Anfrage zur Verbindung mit dem echten Server an den Proxy. Wenn der Proxy auf diese Weise konfiguriert ist, stellt er über SSL eine Verbindung zum echten Server her, aber der Browser spricht weiterhin mit dem Proxy. Wenn also ein Angreifer Zugriff auf den Proxy erhält, kann er alle Daten, die durch ihn fließen, im Klartext sehen.

Ihre Anfragen werden auch im Browserverlauf sichtbar. Die Nutzer könnten versucht sein, die Website als Lesezeichen zu speichern. Einige Nutzer haben Tools zur Synchronisierung von Lesezeichen installiert, so dass das Passwort auf deli.ci.us oder an einem anderen Ort landen könnte.

Und schließlich könnte jemand Ihren Computer gehackt und einen Tastatur-Logger oder einen Screen-Scraper installiert haben (was bei vielen Viren vom Typ Trojanisches Pferd der Fall ist). Da das Kennwort direkt auf dem Bildschirm sichtbar ist (im Gegensatz zu "*" in einem Kennwortdialog), ist dies eine weitere Sicherheitslücke.

Schlussfolgerung: Wenn es um Sicherheit geht, sollte man sich immer auf die ausgetretenen Pfade verlassen. Es gibt einfach zu viel, was Sie nicht wissen, woran Sie nicht denken und was Ihnen das Genick brechen wird.