wake-up-neo.com

Sind Sicherheitsbedenken beim Senden eines Kennworts mithilfe einer GET-Anforderung über https gültig?

Wir haben eine Webseite, die das sapui5 - Framework verwendet, um ein spa zu erstellen. Die Kommunikation zwischen dem Browser und dem Server erfolgt mit https . Die Interaktion zum Anmelden auf der Seite ist wie folgt:

  1. Der Benutzer öffnet die Website, indem er im Browser https://myserver.com eingibt
  2. Ein Anmeldedialog mit zwei Formularfeldern für Benutzername und Passwort wird angezeigt.
  3. Nachdem Sie username und password eingegeben und den login-button gedrückt haben
  4. eine Ajax-Anfrage wird mit GET an die URL gesendet: https://myusername:[email protected]/foo/bar/metadata

Nach meinem Verständnis ist es nie eine gute Idee, GET zum Senden sensibler Daten zu verwenden. Aber diese Antwort auf HTTPS ist die URL-Zeichenfolge secure sagt Folgendes

HTTPS Establishes an underlying SSL conenction before any HTTP data is
transferred. This ensures that all URL data (with the exception of
hostname, which is used to establish the connection) is carried solely
within this encrypted connection and is protected from
man-in-the-middle attacks in the same way that any HTTPS data is.

In einer anderen Antwort im selben Thread:

These fields [for example form field, query strings] are stripped off
of the URL when creating the routing information in the https packaging 
process by the browser and are included in the encrypted data block.

The page data (form, text, and query string) are passed in the
encrypted block after the encryption methods are determined and the
handshake completes.

Es scheint jedoch immer noch Sicherheitsbedenken bei der Verwendung von get zu geben:

Gilt das für URLs wie?

    https://myusername:[email protected]/foo/bar/metadata
    // or 
    https://myserver.com/?user=myUsername&pass=MyPasswort

Zusätzliche Fragen zu diesem Thema:

Auf security.stackexchange finden Sie zusätzliche Informationen:

Meiner Meinung nach werden einige Aspekte immer noch nicht beantwortet

Frage

Meiner Meinung nach sind die genannten Punkte berechtigte Einwände, nicht benutzt zu werden. Ist das der Fall; Ist die Verwendung von get zum Senden von Passwörtern eine schlechte Idee?

Sind das die Angriffsoptionen, gibt es mehr?

  • browserverlauf
  • server-Protokolle (unter der Annahme, dass die URL unverschlüsselt oder verschlüsselt in den Protokollen gespeichert ist)
  • referer Information (wenn dies wirklich der Fall ist)

Welche Angriffsmöglichkeiten gibt es, wenn sensible Daten (Passwort) mit get über https gesendet werden?

Vielen Dank

21
surfmuggle

Diese beiden Ansätze unterscheiden sich grundlegend:

  • https://myusername:[email protected]/foo/bar/metadata
  • https://myserver.com/?user=myUsername&pass=MyPasswort

myusername:[email protected] ist die "User Information" (dieses Formular ist im neuesten URI-RFC nicht mehr aktuell), während ?user=myUsername&pass=MyPasswort Teil der Abfrage ist.

Wenn Sie dieses Beispiel aus RFC 3986 betrachten:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

myusername:[email protected] ist Teil der Authority . In der Praxis werden im Allgemeinen HTTP-Authentifizierungs-Header (Basic) verwendet, um diese Informationen zu übermitteln. Auf der Serverseite werden Kopfzeilen im Allgemeinen nicht protokolliert (und wenn dies der Fall ist, spielt es keine Rolle, ob der Client sie in die Adressleiste oder über einen Eingabedialog eingegeben hat). Im Allgemeinen (obwohl die Implementierung von der Implementierung abhängig ist), wird sie von Browsern nicht in der Adressleiste gespeichert oder zumindest wird das Kennwort entfernt. Es scheint, dass Firefox die Benutzerinformationen im Browserverlauf speichert, während Chrome dies nicht tut (und IE unterstützt sie nicht wirklich, ohne umzugehen ).

Im Gegensatz dazu ist ?user=myUsername&pass=MyPasswort die query , ein wesentlich integrierterer Teil der URI, und es wird als HTTP-Request-URI gesendet. Dies wird im Verlauf des Browsers und in den Protokollen des Servers angezeigt. Dies wird auch im Referrer weitergegeben.

Einfach ausgedrückt, myusername:[email protected] ist eindeutig dafür ausgelegt, potenziell sensible Informationen zu übermitteln, und Browser sind im Allgemeinen dafür ausgelegt, dies angemessen zu behandeln, wohingegen Browser nicht erraten können, welcher Teil der Abfragen empfindlich ist und welche nicht: Informationsverlust dort.


Die Referrer-Informationen werden im Allgemeinen auch nicht an Dritte weitergegeben, da der Referer-Header, der von einer HTTPS-Seite stammt, normalerweise nur mit einer anderen Anforderung von HTTPS an denselben Host gesendet wird. (Wenn Sie https://myserver.com/?user=myUsername&pass=MyPasswort verwendet haben, ist dies natürlich in den Protokollen desselben Hosts, aber Sie machen es nicht viel wert, da es in den gleichen Serverprotokollen bleibt.)

Dies ist in der HTTP-Spezifikation (Abschnitt 15.1.3) angegeben :

Clients SOLLTEN NICHT ein Referer-Headerfeld in eine (nicht sichere) HTTP-Anforderung einschließen, wenn die verweisende Seite mit einem sicheren Protokoll übertragen wurde. 

Obwohl es nur ein "SOLL NICHT" ist, scheinen Internet Explorer, Chrome und Firefox es so zu implementieren. Ob dies für HTTPS-Anfragen von einem Host zu einem anderen gilt, hängt vom Browser und seiner Version ab.

Es ist jetzt möglich, dieses Verhalten zu überschreiben, wie in diese Frage und diese Entwurfsspezifikation beschrieben, wobei ein <meta>-Header verwendet wird. Dies ist jedoch auf einer vertraulichen Seite, die ?user=myUsername&pass=MyPasswort ohnehin verwendet, nicht möglich.

Beachten Sie, dass der Rest der HTTP-Spezifikation (Abschnitt 15.1.3) auch relevant ist:

Autoren von Diensten, die das HTTP-Protokoll verwenden, SOLLTEN NICHT GET-basierte Formulare für die Übermittlung sensibler Daten verwenden, da dies dazu führt, dass diese Daten in der Request-URI codiert werden. Viele vorhandene Server, Proxies und Benutzeragenten protokollieren die Anforderungs-URI an einem Ort, an dem sie möglicherweise für Dritte sichtbar ist. Server können stattdessen POST-basierte Formularübermittlung verwenden 

Die Verwendung von ?user=myUsername&pass=MyPasswort ist genau wie die Verwendung eines GET-basierten Formulars. Auch wenn das Referer-Problem enthalten sein kann, bleiben die Probleme bezüglich der Protokolle und des Verlaufs bestehen.

17
Bruno

Das Senden von sensiblen Daten über GET ist gefährlich, auch wenn es sich um HTTPS handelt. Diese Daten können in Protokolldateien auf dem Server enden und in der Referer-Kopfzeile in Links zu oder von anderen Seiten enthalten sein. Sie werden auch im Verlauf des Browsers gespeichert, sodass ein Angreifer versuchen könnte, den ursprünglichen Inhalt des Links mit einem Angriff auf den Verlauf zu erraten und zu überprüfen.

Ansonsten stellen Sie solche Fragen besser auf security.stackexchange.com.

24
Steffen Ullrich

Bedenken Sie:

https://www.example.com/login

Javascript innerhalb der Login-Seite:

$.getJSON("/login?user=joeblow&pass=securepassword123");

Was wäre der Referer jetzt?

Wenn Sie sich Sorgen um die Sicherheit machen, könnte eine zusätzliche Schicht sein:

var a = Base64.encode(user.':'.pass);
$.getJSON("/login?a="+a);

Obwohl nicht verschlüsselt, sind zumindest die Daten vor dem bloßen Blick verdeckt.

0
Jay

Angenommen, der Benutzer hat auf eine Schaltfläche geklickt und die folgende Anfrage wird vom Client-Browser generiert.

https://www.site.com/?username=alice&password=b0b123 !

HTTPS

Alles der Reihe nach. HTTPS steht in keinem Zusammenhang mit diesem Thema. Die Verwendung von POST oder GET spielt in der Angreiferperspektive keine Rolle. Angreifer können vertrauliche Daten einfach aus der Abfragezeichenfolge oder direkt aus dem Anforderungshauptteil POST holen, wenn der Datenverkehr HTTP ist. Deshalb macht es keinen Unterschied.

Serverprotokolle

Wir wissen, dass Apache, Nginx oder andere Dienste jede einzelne HTTP-Anforderung in der Protokolldatei protokollieren. Dies bedeutet, dass die Abfragezeichenfolge (? Username = alice & password = b0b123!) In die Protokolldateien geschrieben wird. Dies kann gefährlich sein, da Ihr Systemadministrator auch auf diese Daten zugreifen und alle Benutzeranmeldeinformationen abrufen kann. Es kann auch ein anderer Fall eintreten, wenn der Anwendungsserver gefährdet ist. Ich glaube, Sie speichern das Passwort als Hash. Wenn Sie einen leistungsstarken Hash-Algorithmus wie SHA256 verwenden, ist das Kennwort Ihres Clients vor Hackern sicherer. Hacker können jedoch auf Protokolldateien direkt zugreifen und erhalten Passwörter als Nur-Text mit sehr einfachen Shell-Skripts. 

Referer Information  

Wir gingen davon aus, dass der Client über dem Link geöffnet wurde. Wenn der Client-Browser den HTML-Inhalt abruft und versucht, ihn zu analysieren, wird das Image-Tag angezeigt. Diese Bilder können von außerhalb Ihrer Domain gehostet werden (Postimage- oder ähnliche Dienste oder direkt unter einer Domäne, die unter der Kontrolle des Hackers steht). Browser machen eine HTTP-Anfrage, um ein Bild zu erhalten. Die aktuelle URL ist jedoch https://www.site.com/?username=alice&password=b0b123 ! was wird referer information sein!

Das bedeutet, dass alice und ihr Passwort an eine andere Domain weitergegeben werden und direkt über Webprotokolle aufgerufen werden können. Dies ist ein wirklich wichtiger Sicherheitsaspekt. 

Dieses Thema erinnert mich an die Sicherheitsanfälligkeiten bei der Sitzungsfixierung. Bitte lesen Sie den folgenden OWASP-Artikel für fast dieselben Sicherheitslücken wie bei Sitzungen. ( https://www.owasp.org/index.php/Session_fixation ) Es lohnt sich, es zu lesen.

0
Mehmet Ince

Die Gemeinschaft hat einen breiten Überblick über die Überlegungen gegeben, die oben genannten Punkte in Bezug auf die Frage. Im Allgemeinen benötigen GET-Anforderungen jedoch eine Authentifizierung. Wie oben erwähnt, ist das Senden eines Benutzernamens/Kennworts als Teil der URL niemals korrekt. Dies ist jedoch normalerweise nicht die Art und Weise, wie Authentifizierungsinformationen behandelt werden. Wenn eine Anforderung für eine Ressource an den Server gesendet wird, antwortet der Server im Allgemeinen mit einem 401 und einem Authentifizierungsheader in der Antwort, gegen den der Client einen Autorisierungsheader mit den Authentifizierungsinformationen sendet (im Basisschema). Diese zweite Anfrage vom Client kann nun eine POST oder eine GET-Anfrage sein, nichts hindert das daran. Im Allgemeinen handelt es sich also nicht um den Anfragetyp, sondern um die Art der Übermittlung der Informationen.

Siehe http://en.wikipedia.org/wiki/Basic_access_authentication

0
Ironluca