it-swarm.com.de

Ist eine HTTPS-Abfragezeichenfolge sicher?

Ich erstelle eine sichere webbasierte API, die HTTPS verwendet. Wenn ich jedoch zulasse, dass die Benutzer das Kennwort mithilfe einer Abfragezeichenfolge konfigurieren (einschließlich des Sendens eines Kennworts), ist dies auch sicher, oder muss ich erzwingen, dass dies über einen POST erfolgt?

320
John

Ja ist es. Die Verwendung von GET für vertrauliche Daten ist jedoch eine schlechte Idee aus mehreren Gründen:

  • Meistens HTTP-Referrer-Leck (ein externes Bild auf der Zielseite kann das Passwort verlieren [1])
  • Passwort wird in Server Logs gespeichert (was offensichtlich schlecht ist)
  • Verlaufs-Caches in Browsern

Obwohl Querystring gesichert ist, wird daher nicht empfohlen, vertrauliche Daten über Querystring zu übertragen.

[1] Obwohl ich beachten muss, dass RFC angibt, dass der Browser keine Verweise von HTTPS an HTTP senden soll. Dies bedeutet jedoch nicht, dass eine schlechte Browser-Symbolleiste von Drittanbietern oder ein externes Bild/Flash von einer HTTPS-Site keine Daten verlieren.

418
dr. evil

Aus Sicht von "sniff the network packet" ist eine GET-Anfrage sicher, da der Browser zuerst die sichere Verbindung herstellt und dann die Anfrage mit den GET-Parametern sendet. GET-URLs werden jedoch im Browserverlauf/Autocomplete des Benutzers gespeichert, was kein guter Ort zum Speichern von z. Passwortdaten in. Dies gilt natürlich nur, wenn Sie die umfassendere "Webservice" -Definition verwenden, die möglicherweise über einen Browser auf den Dienst zugreift. Wenn Sie nur über Ihre benutzerdefinierte Anwendung auf den Dienst zugreifen, sollte dies kein Problem sein.

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

69
VolkA

Ja, Ihre Abfragezeichenfolgen werden verschlüsselt.

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

Wenn Sie eine SSL-Verbindung herstellen, führt Ihr Client die folgenden Schritte der Reihe nach aus. Angenommen, Sie versuchen, sich bei einer Site mit dem Namen example.com anzumelden und möchten Ihre Anmeldeinformationen mithilfe von Abfrageparametern senden. Ihre vollständige URL könnte folgendermaßen aussehen:

https://example.com/login?username=alice&password=12345)
  1. Ihr Client (z. B. Browser/mobile App) löst Ihren Domain-Namen example.com Zunächst mithilfe einer DNS-Anfrage in eine IP-Adresse (124.21.12.31) Auf. Bei der Abfrage dieser Informationen werden nur domänenspezifische Informationen verwendet, d. H. Es wird nur example.com Verwendet.
  2. Jetzt versucht Ihr Client, eine Verbindung zum Server mit der IP-Adresse 124.21.12.31 Herzustellen und versucht, eine Verbindung zu Port 443 herzustellen (SSL-Service-Port nicht der Standard-HTTP-Port 80).
  3. Nun sendet der Server bei example.com Seine Zertifikate an Ihren Client.
  4. Ihr Client überprüft die Zertifikate und beginnt, einen gemeinsamen geheimen Schlüssel für Ihre Sitzung auszutauschen.
  5. Nach erfolgreichem Aufbau einer sicheren Verbindung werden Ihre Abfrageparameter erst dann über die sichere Verbindung gesendet.

Aus diesem Grund werden Sie keine vertraulichen Daten preisgeben. Das Senden Ihrer Anmeldeinformationen über eine HTTPS-Sitzung mit dieser Methode ist jedoch nicht der beste Weg. Sie sollten einen anderen Ansatz wählen.

37
Ruchira Randana

Ja. Der gesamte Text einer HTTPS-Sitzung ist durch SSL gesichert. Das schließt die Abfrage und die Überschriften ein. In dieser Hinsicht wären ein POST und ein GET genau dasselbe.

Was die Sicherheit Ihrer Methode anbelangt, gibt es keine wirkliche Möglichkeit, dies ohne ordnungsgemäße Prüfung zu sagen.

25
shoosh

SSL stellt zunächst eine Verbindung zum Host her, sodass der Hostname und die Portnummer als Klartext übertragen werden. Wenn der Host antwortet und die Abfrage erfolgreich ist, verschlüsselt der Client die HTTP-Anforderung mit der tatsächlichen URL (d. H. Nach dem dritten Schrägstrich) und sendet sie an den Server.

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

Es ist möglich, einen Proxy als "Mann in der Mitte" zu konfigurieren. Grundsätzlich sendet der Browser die Anforderung, eine Verbindung zum realen Server herzustellen, an den Proxy. Wenn der Proxy auf diese Weise konfiguriert ist, wird eine Verbindung über SSL zum realen Server hergestellt, der Browser kommuniziert jedoch weiterhin mit dem Proxy. Wenn ein Angreifer Zugriff auf den Proxy erhält, kann er alle durch ihn fließenden Daten im Klartext anzeigen.

Ihre Anfragen werden auch im Browserverlauf angezeigt. Benutzer könnten versucht sein, Lesezeichen für die Site zu setzen. Einige Benutzer haben Lesezeichen-Synchronisierungstools installiert, sodass das Kennwort möglicherweise auf deli.ci.us oder an einem anderen Ort gespeichert wird.

Schließlich hat möglicherweise jemand Ihren Computer gehackt und einen Tastatur-Logger oder einen Bildschirm-Scraper installiert (und viele Trojaner-Viren). Da das Kennwort direkt auf dem Bildschirm angezeigt wird (im Gegensatz zu "*" in einem Kennwortdialog), ist dies eine weitere Sicherheitslücke.

Fazit: Wenn es um Sicherheit geht, verlassen Sie sich immer auf den ausgetretenen Pfad. Es gibt einfach zu viel, an das Sie nicht denken und das Ihnen den Hals brechen wird.

22
Aaron Digulla

Ja, solange niemand über die Schulter auf den Monitor schaut.

10
Ali Afshar

Ich stimme der Aussage über [...] HTTP-Referrer-Leakage nicht zu (ein externes Bild auf der Zielseite könnte das Passwort lecken) in - Sloughs Antwort .

Der HTTP 1.1 RFC gibt explizit an :

Clients DÜRFEN KEIN Referer-Header-Feld in eine (nicht sichere) HTTP-Anforderung aufnehmen, wenn die verweisende Seite mit einem sicheren Protokoll übertragen wurde.

Auf jeden Fall sind Serverprotokolle und der Browserverlauf mehr als ausreichende Gründe, um vertrauliche Daten nicht in die Abfragezeichenfolge aufzunehmen.

9
Arnout

Ja, von dem Moment an, an dem Sie eine HTTPS-Verbindung herstellen, ist alles sicher. Die Abfragezeichenfolge (GET) als POST) wird über SSL gesendet.

8
Drejc