Wenn die Abfragezeichenfolge das Ziel eines vom Benutzer anklickbaren Links ist (im Gegensatz zu einer URL, die in Javascript verwendet wird), wird sie beim Laden der entsprechenden Seite in der URL-Leiste des Browsers angezeigt. Es gibt folgende Probleme:

• Die URL wird angezeigt. Schulter-Surfer können es sehen und daraus lernen (z. B. ein Passwort).
• Der Benutzer kann es mit einem Lesezeichen versehen. Dies kann eine Funktion sein; Es bedeutet aber auch, dass die Daten auf die Festplatte geschrieben werden.
• In ähnlicher Weise schafft es die URL in den "Verlauf", sodass sie trotzdem auf die Festplatte geschrieben wird. und es könnte später abgerufen werden. Wenn der Browser beispielsweise Chrome ist, muss ein Angreifer zur Mittagszeit nur Strg + H eingeben, um die Registerkarte "Verlauf" zu öffnen und alle Abfragezeichenfolgen abzurufen.
• Wenn die Seite gedruckt wird, die URL wird gedruckt, einschließlich vertraulicher Informationen.
• URLs einschließlich Abfragezeichenfolgen werden häufig auch auf dem Webserver protokolliert, und diese Protokolle werden möglicherweise nicht ordnungsgemäß gesichert.
• Es gibt Größenbeschränkungen für die Abfragezeichenfolge, die vom Browser und vom Server abhängt (hier gibt es nichts wirklich Standard, aber erwarten Sie Probleme über 4 kB hinaus).

Wenn die Abfragezeichenfolge daher ein einfacher Link ist Ziel in einer HTML-Seite, dann sollten vertrauliche Daten als Teil eines POST-Formulars übertragen werden, nicht in der URL selbst codiert. Bei programmatischen Downloads (nach AJAX-Methode) ist dies weniger ein Problem.

Zusätzlich zu den anderen Antworten hier wird die Abfragezeichenfolge auch in den Protokolldateien des Webservers, HTTP-Proxies, gespeichert und kann sogar angezeigt werden, wenn SSL in Verbindung mit SSL-Überwachungstools wie Bluecoat verwendet wird.

Nein , vertrauliche Daten sollten nicht über ein HTTP "GET" gesendet werden und sollten immer über "POST" gesendet werden.

Bearbeiten:

Ein weiterer Grund, warum Sie einen POST verwenden sollten, ist, dass GETs anfälliger für CSRF-Angriffe

Vertrauliche Daten sollten entweder übergeben werden:

1. Sichere Nur-HTTP-Cookies (sicher bedeutet nur SSL; und nur HTTP bedeutet, dass Javascript nicht zugreifen kann) (z. B. ein zufälliges Token, das dies identifiziert Sie haben sich angemeldet) oder
2. POST-Variablen (über SSL).
ol>

Drei Gründe:

1. Ihr Computer ist normalerweise standardmäßig Protokolliert die Abfragezeichenfolge (im Browserverlauf).
2. Der Webserver am anderen Ende protokolliert standardmäßig die Abfragezeichenfolge. Dies ist schlecht, wenn beispielsweise Passwörter weitergegeben werden, dass der Webserver intelligent nur starke, durch Schlüssel verstärkte kryptografische Hashes mit zufälligen Salzen (z. B. bcrypt) speichert, um zu verhindern, dass die Passwörter versehentlich von Angreifern abgerufen werden. Offensichtlich ist es nicht schwer, POST-Variablen zu protokollieren, wenn dies erforderlich ist, aber dies wird normalerweise nicht durchgeführt.
3. Sensible Daten sollten im Allgemeinen nur übergeben werden, wenn eine Aktion basierend auf diesen sensiblen Daten ausgeführt wird. In Fällen, in denen Sie eine Aktion ausführen (z. B. Anmelden; Übergeben sicherer Daten, die in einer Datenbank gespeichert / verarbeitet werden sollen), sollten Sie POST im Vergleich zu GET verwenden.
ol>

Im Allgemeinen gelten die Regeln Diese verhindern, dass standortübergreifende Anforderungsfälschungen (CSRF, auch als XSRF bezeichnet) nur für POST-Anforderungen ausgelöst werden. GET ist die beabsichtigte HTTP-Anforderungsmethode zum Abrufen von Daten von einem Webserver, die keine anderen Auswirkungen hat (abgesehen von harmlosen Dingen wie dem Auffüllen einer Protokolldatei, die besagt, dass diese Seite angefordert wurde). POST ist das Protokoll, mit dem ein Benutzer Daten sendet, um eine Aktion auszuführen (z. B. etwas von einer Website bestellen, Geld von Ihrem Bankkonto überweisen, Ihr Passwort ändern). Dies ist ein zufälliges CSRF-Token, das normalerweise von den meisten Frameworks für GET-Anforderungen benötigt wird, jedoch häufig für POST-Anforderungen erforderlich ist.

(Und während Thomas Pornin und makerofthings7 1 und 2 berührten, habe ich beide zuvor in einer etwas ähnlichen Frage erwähnt.)

Wenn es vermieden werden kann, vermeide ich es immer. Es ist nur eine weitere Angriffsfläche, die geschlossen bleiben sollte, es sei denn, es gibt eine legitime Notwendigkeit , damit Daten in der Abfragezeichenfolge übergeben werden können.

Es gibt immer auch die Möglichkeit, dass Sie oder ein zukünftiger Entwickler die Daten nicht richtig filtern / bereinigen und die Angriffsfläche noch weiter öffnen. Selbst in einer unsicheren App können Sie, wenn Sie versehentlich eine Injektion zulassen, einen böswilligen Angreifer und XSS- und XSRF-Skript in Ihre Datenbank einfügen und Ihre nicht sensible App verwenden, um andere anzugreifen. Gehen Sie also am besten auf Nummer sicher.

Schulter-Surfen ist je nach Umgebung ein weiteres berechtigtes Anliegen. Wenn Ihre App an einem Ort verwendet werden soll, an dem dies möglich ist (eine Bibliothek, eine Kabine, in die jemand schauen kann, und ein Büro mit einem Schreibtisch in die falsche Richtung usw.), ist dies ein potenzielles Problem. Wenn sich die Benutzer Ihrer App alle in Räumen befinden, in denen der Schreibtisch so ausgerichtet ist, dass das Surfen auf der Schulter kein Problem darstellt, machen Sie sich darüber keine Sorgen. Aber wenn Sie das nicht sicher wissen und nicht wissen, dass es immer so sein wird, ist dies ein Problem.

Basierend auf dem OWASP REST-Sicherheits-Spickzettel https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

In GET-Anforderungen sollten vertrauliche Daten übertragen werden in einem HTTPHeader.

Es ist erwähnenswert, dass Abfragezeichenfolgen in vielerlei Hinsicht genauso sicher sind wie andere Teile der Anforderung.

• Abfragezeichenfolgen werden mit HTTPS verschlüsselt - ohne ein https MITM sonst niemand wird außerhalb des Computers des Benutzers angezeigt.

• Post-Daten sind für den Endbenutzer in den Entwicklertools

• Header sichtbar sind auch in den Tools sichtbar.

Es ist nicht ungewöhnlich, vertrauliche Daten in Abfragezeichenfolgen zu übergeben.

• Fast sehr OAuth2 / SAML Der Prozess sendet ein Zugriffstoken vom IdP in einer Abfragezeichenfolge an den SP zurück - diese Token sind in der Regel von kurzer Dauer / einmaliger Verwendung -, da der SP es mithilfe einer POST-Anforderung von Server zu Server ersetzt.

• Links zum Zurücksetzen von Passwörtern in E-Mails haben ein Token, das jedoch nach der Verwendung normalerweise ungültig wird.

• Magische Login-Links, die von Slack und anderen verwendet werden, haben dies erneut Einweg-Token in der Abfragezeichenfolge.