Ich erstelle eine sichere webbasierte API, die HTTPS verwendet. Wenn ich den Benutzern jedoch erlaube, es mithilfe einer Abfragezeichenfolge zu konfigurieren (einschließlich des Sendens eines Kennworts), ist dies auch sicher, oder sollte ich erzwingen, dass dies über einen POST erfolgt?
Antworten:
Ja, so ist es. Die Verwendung von GET für vertrauliche Daten ist jedoch aus mehreren Gründen eine schlechte Idee :
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 eines Drittanbieters oder ein externes Bild / Flash von einer HTTPS-Site nicht durchgesickert ist.
History caches in browsersoder eine Referenz für ir hinzufügen?
Unter dem Gesichtspunkt "Sniff the Network Packet" ist eine GET-Anforderung sicher, da der Browser zuerst die sichere Verbindung herstellt und dann die Anforderung mit den GET-Parametern sendet. GET-URLs werden jedoch im Browserverlauf / in der automatischen Vervollständigung des Benutzers gespeichert. Dies ist kein guter Ort zum Speichern von z. B. Kennwortdaten. Dies gilt natürlich nur, wenn Sie die umfassendere Definition "Webservice" verwenden, die möglicherweise über einen Browser auf den Dienst zugreift. Wenn Sie nur über Ihre benutzerdefinierte Anwendung darauf zugreifen, sollte dies kein Problem sein.
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 eher in Ihre Serverprotokolle geschrieben.
Ja , Ihre Abfragezeichenfolgen werden 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. Zuerst wird die SSL-Verbindung hergestellt und dann werden die Abfrageparameter (die zum HTTP-Protokoll gehören) an den Server gesendet.
Beim Herstellen einer SSL-Verbindung führt Ihr Client die folgenden Schritte der Reihe nach aus. Angenommen, Sie möchten sich bei einer Site mit dem Namen example.com anmelden und Ihre Anmeldeinformationen mithilfe von Abfrageparametern senden. Ihre vollständige URL sieht möglicherweise folgendermaßen aus:
https://example.com/login?username=alice&password=12345)
example.comin eine IP-Adresse (124.21.12.31)auf. Bei der Abfrage dieser Informationen werden nur domänenspezifische Informationen verwendet, dh nur example.comdiese.124.21.12.31und versucht, eine Verbindung zu Port 443 herzustellen (SSL-Service-Port nicht der Standard-HTTP-Port 80).example.comsendet der Server at seine Zertifikate an Ihren Client.Daher werden Sie keine sensiblen Daten verfügbar machen. Das Senden Ihrer Anmeldeinformationen über eine HTTPS-Sitzung mit dieser Methode ist jedoch nicht der beste Weg. Sie sollten einen anderen Ansatz wählen.
(e.g http://example.com/login?username=alice&password=12345).
Ja. Der gesamte Text einer HTTPS-Sitzung ist durch SSL gesichert. Dazu gehören die Abfrage und die Header. In dieser Hinsicht wären ein POST und ein GET genau gleich.
Was die Sicherheit Ihrer Methode betrifft, gibt es keine wirkliche Möglichkeit, dies ohne ordnungsgemäße Prüfung zu sagen.
SSL stellt zuerst eine Verbindung zum Host her, sodass der Hostname und die Portnummer als Klartext übertragen werden. Wenn der Host antwortet und die Herausforderung erfolgreich ist, verschlüsselt der Client die HTTP-Anforderung mit der tatsächlichen URL (dh nach dem dritten Schrägstrich) und sendet sie an den Server.
Es gibt verschiedene Möglichkeiten, diese Sicherheit zu verletzen.
Es ist möglich, einen Proxy so zu konfigurieren, dass er als "Mann in der Mitte" fungiert. Grundsätzlich sendet der Browser die Anforderung, eine Verbindung zum realen Server herzustellen, an den Proxy. Wenn der Proxy auf diese Weise konfiguriert ist, stellt er über SSL eine Verbindung zum realen Server her, der Browser kommuniziert jedoch weiterhin mit dem Proxy. Wenn ein Angreifer also Zugriff auf den Proxy erhalten kann, kann er alle Daten, die durch den Proxy fließen, im Klartext sehen.
Ihre Anfragen werden auch im Browserverlauf angezeigt. Benutzer könnten versucht sein, die Site mit einem Lesezeichen zu versehen. Einige Benutzer haben Lesezeichen-Synchronisierungstools installiert, sodass das Kennwort möglicherweise auf deli.ci.us oder einem anderen Ort landet.
Schließlich hat möglicherweise jemand Ihren Computer gehackt und einen Tastaturlogger oder einen Bildschirmschaber installiert (und viele Viren vom Typ Trojanisches Pferd tun dies). 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, das Sie nicht wissen, an das Sie nicht denken und das Ihnen den Hals brechen wird.
Ja, solange niemand über die Schulter auf den Monitor schaut.
Ich bin nicht mit der Aussage über [...] HTTP-Referrer-Leckage (ein externes Bild auf der Zielseite könnte das Passwort verlieren) in Sloughs Antwort einverstanden .
Der HTTP 1.1-RFC gibt explizit an :
Clients sollten ein Referer-Header-Feld NICHT 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 ausreichend, um keine vertraulichen Daten in die Abfragezeichenfolge aufzunehmen.
Sie können das Passwort als MD5-Hash-Parameter mit etwas Salz senden. Vergleichen Sie es auf der Serverseite für die Authentifizierung.