Option 1 kann ohnehin eine Reihe von nicht sicherheitsrelevanten Problemen verursachen:

• Die resultierende URL wird möglicherweise vom Browser zwischengespeichert oder mit einem Lesezeichen versehen, wodurch Benutzer erneut einreichen.
• Die resultierende URL kann von Benutzern geteilt werden, was zur Übermittlung durch Dritte führt.
• Die URL wird möglicherweise an Ihren Browser-Anbieter gesendet, der möglicherweise auf die Website gelangt.

Hier geht es jedoch um Sicherheit, und es werden einige Risiken eingeführt, die in Option 2 nicht vorhanden sind:

• Die URL mit ihrem Parameter kann in den Proxy-Protokollen von allem landen Auf dem Weg dorthin enthüllen Sie Ihre Daten.
• Ihre Dekodierungsfunktion ist jetzt ein zusätzlicher Angriffsvektor. (Behandelt es Unicode korrekt? Hat es Längenbeschränkungen?)
• Sie könnten versucht sein, sich Ihre codierte Zeichenfolge als irgendwie sicher vorzustellen, wenn es sich nur um Sicherheit durch Dunkelheit (und) handelt nicht sehr dunkel) oder besser gesagt Sicherheitstheater.

Das heißt jedoch; Ansonsten sind sie in Bezug auf die von ihnen angebotene Sicherheit weitgehend gleichwertig. Beide senden Klartextdaten im HTTP-Header, und base64 ist nicht gerade ein Hexenwerk (und Sie können Ihre POST-Version mit base64 codieren).

Beides bietet keinen sinnvollen Schutz für Ihre Daten.

Wenn es sich um Informationen handelt, die der Benutzer nicht sehen soll; Warum senden Sie es zunächst an den Benutzer? Betrachten Sie die von Ihnen verwendete Architektur und prüfen Sie, ob es eine Möglichkeit gibt, das Risiko einfach vollständig zu beseitigen, indem Sie diese Informationen nicht auf der Clientseite verarbeiten.

Beantworten Sie also die Frage: In Bezug auf das Senden von Daten - beide geben einem Angreifer die gleichen Informationen preis; Wählen Sie die für die jeweilige Situation am besten geeignete Option aus ( dieser Treehouse-Blogbeitrag kann dabei helfen), aber Sie sollten sich nicht auf eine der beiden Methoden verlassen, um tatsächlich etwas zu schützen.

Es ist einfach, standortübergreifende GET -Anfragen zu stellen, indem ein einfaches <img> -Tag in eine Webseite eingefügt wird. Auf einer Seite von www.evilhacker.com erzeugt Javascript beispielsweise einen langen Strom von <img> -Tags mit vom Angreifer ausgewählten Pfaden, die alle auf www zeigen. targetbank.com - und Ihr Browser enthält das Bank-Cookie in allen Anfragen.

Dies allein bedeutet, dass Sie nicht unterstützt GET -Anforderungen, die eine Änderung auf der Zielwebsite implizieren. In der Regel sollten GET -Anforderungen für Vorgänge reserviert werden, für die Wiederholungsangriffe kein Problem darstellen, dh in der Praxis nur Lesezugriffe auf statische Daten .

Verwenden Sie POST, um Anforderungen zu senden, die Daten auf dem Server ändern.

Nach der HTTP-Spezifikation werden GET-Anforderungen (z. B. Parameter in der URL) abgerufen ) sollte nur für Anfragen zum Abrufen verwendet werden (daher der Name GET), aber keine Daten ändern. POST-Anforderungen (nicht sichtbare Parameter, die in der HTTP-Anforderung jedoch noch nicht verschlüsselt sind) sollten immer dann verwendet werden, wenn die Anforderung Daten erstellt / aktualisiert / ändert, die in der Datenbank gespeichert werden sollen (außer Standardprotokollen). Dies macht es für Angreifer etwas schwieriger, Fälschungen von standortübergreifenden Anforderungen durchzuführen, und es ist weniger wahrscheinlich, dass geheime Informationen versehentlich doppelt in Ihrem Webseitenverlauf / in Ihren Webserverprotokollen übermittelt oder gespeichert werden.

Ist die Pin-Variable ein Geheimnis?

Was Sie gerade tun, scheint abhängig von der Bedeutung des Pin code unsicher zu sein > Variable. Muss dies vor potenziellen Lauschern geheim gehalten werden oder könnten Leute, die den Stift abfangen, damit einen Angriff ausführen? Verwenden Sie in diesem Fall nur HTTPS (für die End-to-End-Verschlüsselung über die Transportschicht) für jede Anforderung mit diesen geheimen Daten. Der von Ihnen verwendete Basis-64-Wert schien 3000670269 zu sein (vorausgesetzt, ich musste zwei Gleichheitszeichen anhängen, um eine ordnungsgemäße b64-Codierung zu erhalten).

Was würde passieren, wenn ein Angreifer versuchen würde, andere Pins zu verwenden?

Nehmen wir an, mein pin = '300670269' , aber um Ihr System zu testen, habe ich MzAwMDY3MDI1OQ gesendet (für pin = '3000670259' ). Würden sie dann effektiv in ein anderes Benutzerkonto einbrechen? Wenn ja, sollten Sie zumindest eine zusätzliche POST-Variable wie Prüfsumme = SHA256 (Pin + secret_server_side_string) verwenden, wobei secret_server_side_string eine lange zufällige Zeichenfolge ist (z Etwas wie de10RRORX50UAUhx0dDIxJnzXKBAs68yjdWVz8QQ - 40 zufällige obere + untere + Zahlenzeichen hat lg (62) * 40 = 238 Bit Entropie), und Ihre Anwendungen wirken nur auf den Pin, wenn Die Prüfsumme entspricht dem Stift. Ihre Anwendung sollte die Prüfsumme generieren (ohne dem Client die geheime_server_side_string mitzuteilen). Sie müssen auch darauf achten, dass Ihre Anwendung zeitlich konstante Zeichenfolgenvergleiche durchführt, wenn Sie die Prüfsumme mit dem Pin überprüfen, damit Ihre Anwendung nicht für Timing-Angriffe anfällig ist.

Es gibt kürzlich einen interessanten Angriff, der ausgenutzt wurde, um Webanwendungs-Firewall-Regeln zu umgehen, die als " HTTP-Parameter-Verschmutzungsangriff" bekannt sind. Ich werde dies anhand eines Beispiels wie

  POST /index.aspx?par=1&par=2 HTTP / 1.1Benutzer-Agent: Mozilla / 5.0Host: HostCookie: par = 5; par = 6Content-Length: 19par = 3&par = 4  

Für diese Post-Request-Anwendung hängt das Verhalten der Anwendung vom Entwickler und dergleichen für Java ab.

1. javax. servlet.ServletRequestInterface (direkte Analyse von Abfragezeichenfolgen)
2. java.lang.StringgetParameter (java.lang.Stringname) Gibt den Wert eines Anforderungsparameters als Zeichenfolge zurück oder null, wenn der Parameter nicht vorhanden ist
3. java.lang.String [] getParameterValues ​​(java.lang.Stringname) Gibt ein Array von String-Objekten zurück, die alle Werte des angegebenen Anforderungsparameters enthalten, oder null, wenn der Parameter nicht vorhanden ist.

Zusätzlich zu Bobs Antwort gibt es einen weiteren Sicherheitsnachteil bei der Verwendung von GET-Anforderungen mit vertraulichen Parametern.

Die URL, die die vertraulichen Informationen enthält, wird an Webserver von Drittanbietern gesendet, auf denen Ressourcen gehostet werden referenziert von der resultierenden HTML-Seite.

Beispiel:

Erste Anforderung:

  GET /someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ HTTP / 1.0Host: domain  

Antwort auf diese Anfrage:

  HTTP / 1.0 OK Inhaltstyp: text / html<img src = "http: //thirdparty/hello.jpg" / >  

Der Webbrowser rendert den HTML-Code und versucht, das Bild wie folgt abzurufen:

  GET /hello.jpg HTTP / 1.0Host: ThirdpartyReferer: http: / /domain/someCode/pages/somePage.jsf?pin=MzAwMDY3MDI2OQ 

Dies kann insbesondere dann ein Problem sein, wenn der auf der Seite gerenderte HTML-Code von Angreifern gesteuert wird (bis zu einem gewissen Grad mit HTML auf der Whitelist) ). Ein Webmail-Dienst, der die Sitzung in die URL einfügt, ermöglicht es Angreifern beispielsweise, ein Bild im HTML-Text der E-Mail zu senden, das auf den Webserver / das Skript des Angreifers verweist. Dann muss der Angreifer beim Rendern des Bildes einfach der URL im Header Referer folgen, die vom Webbrowser des Opfers gesendet wurde. Diese Art von Sicherheitsanfälligkeit hatte in der Vergangenheit tatsächlich Auswirkungen auf Excite Mail (wir sprechen hier von Geschichte :)) und einige andere Webmail-Dienste.

Ein weiterer zu berücksichtigender Sicherheitsfaktor ist, dass die Zugriffsprotokolle des Webservers normalerweise die angeforderten URLs erfassen, einschließlich der Parameter für Abfragezeichenfolgen. Wenn Sie nicht möchten, dass die Abfragezeichenfolge protokolliert wird, müssen Sie möglicherweise auf eine POST-Anforderung zurückgreifen.

Bei der Entscheidung zwischen GET und POST müssen natürlich nicht sicherheitsrelevante Faktoren berücksichtigt werden Anforderungen, z. B. das Verhalten des Browsers beim erneuten Laden der Seite oder beim Abrufen der Seite über die Schaltfläche Zurück des Browsers.