webentwicklung-frage-antwort-db.com.de

Ist es sicher, window.location.href ohne Validierung direkt zu verwenden

Ist die Verwendung von window.location.href ohne Validierung sicher?

Zum Beispiel:

<script>
    var value = window.location.href;
    alert(value);
</script>

Ist es im obigen Beispiel anfällig für Cross-Site Scripting (XSS) -Angriffe? Wenn ja, wie dann? Wie kann der Angreifer den Wert von window.location.href an den schädlichen Inhalt anpassen?

Bearbeiten (zweite Situation)

Dies ist die URL: www.example.com?url=www.attack.com

Angenommen, ich habe eine getQueryString () - Funktion, die ohne Validierung einen Wert zurückgibt.

<script> 
    var value = getQueryString('url'); 
    window.location.href = value; 
</script>

Dieselbe Frage: Ist sie anfällig für Cross-Site Scripting (XSS) -Angriffe? Wenn ja, wie? Wie kann ein Angreifer "window.location.href = value" verwenden, um XSS auszuführen?

javascriptsecurityxsshrefwindow.location
11
overshadow

Unter location.href können zwei Dinge verstanden werden:

  1. Verwenden Sie den Wert von location.href, indem Sie ihn in Ihrem Code herumgeben, ihn manipulieren und verwenden, um die Logik in Ihrem Code zu steuern.
  2. Zuweisung von etwas zu location.href, wodurch der Browser zu verschiedenen URLs navigiert.

Der erste, der den Wert verwendet, kann als sicher angesehen werden. Der Wert von location.href ist nichts weiter als eine Zeichenfolge. Natürlich ist dies Teil der Benutzereingabe, Sie möchten sie also nicht an eine eval-Anweisung übergeben. Dies gilt jedoch auch für alle anderen Formen der Benutzereingabe. Tatsächlich ist der Wert von location.href immer eine gültige URL, sodass bestimmte Annahmen über den Inhalt gemacht werden können. In diesem Sinne könnte man argumentieren, es sei (mehr} _ sicherer als die meisten Benutzereingaben. Solange Sie keine falschen Annahmen treffen.

Der zweite ist etwas, mit dem Sie vorsichtig sein sollten. Die Zuweisung nicht validierter Werte kann zu offenen Weiterleitungen führen, die für Phishing verwendet werden können, und darüber hinaus XSS-Probleme, die sich aus der Verwendung von javascript:- und vbscript:-URIs ergeben.

Edit: Wie gefordert, folgt eine detailliertere Erklärung der Probleme bei der Zuordnung zu location.href:

Angenommen, Sie haben eine vom Angreifer kontrollierte Variable foo. Die Quelle kann wirklich alles sein, aber ein Abfragezeichenfolge-Parameter ist ein gutes Beispiel. Wenn Sie den Wert von foo zu location.href zuweisen, was passiert? Nun, der Browser tut sein Bestes, um den Wert als URI zu interpretieren und leitet den Benutzer dann an die resultierende Adresse weiter. In den meisten Fällen wird dadurch ein Laden der Seite ausgelöst. z.B. Wenn value"https://www.google.com/" ist, wird die Startseite von Google geladen. Wenn Sie zulassen, dass dies ohne Benutzerinteraktion geschieht, spricht man von open redirect und wird als Sicherheitsanfälligkeit betrachtet!

Es gibt jedoch Typen von URIs, die das Laden einer Seite nicht auslösen. Ein allgemeines Beispiel für einen solchen URI wäre eines, das nur einen Fragment-Identifikator enthält, z. #quux. Das Zuweisen von location.href würde dazu führen, dass die Seite zu dem Element mit der ID "quux" blättert und nichts anderes tut. Fragment-URIs sind sicher, solange Sie mit den Werten der Fragmente selbst nichts Dummes tun.

Dann zum interessanten Teil: javascript: und vbscript: URIs. Das sind die, die dich beißen werden. Die JavaScript- und VBScript-URI-Schemata sind nicht standardmäßige URI-Schemata, mit denen Code im Kontext der aktuell geöffneten Webseite ausgeführt werden kann. Klingt schlecht, oder? Gut sollte es Betrachten Sie unsere vom Angreifer gesteuerte Variable foo: Alles, was ein Angreifer tun muss, um einen Angriff gegen Ihre Benutzer zu starten, besteht darin, einen Skript-URI in die Variable einzufügen. Wenn Sie es location.href zuweisen, entspricht dies im Wesentlichen dem Aufruf von eval im Skript.

JavaScript-URIs funktionieren in allen modernen Browsern, während VBScript nur im IE ausgeführt wird und die Seite im Quirks-Modus gerendert werden muss.

Schließlich ist noch ein interessantes URI-Schema zu berücksichtigen: der Daten-URI. Daten-URIs sind Dateiliterale: ganze Dateien, die als URIs codiert sind. Sie können zum Kodieren von Dateien einschließlich HTML-Dokumenten verwendet werden. Und diese Dokumente können wie alle anderen Skripte enthalten.

Die meisten Browser behandeln jeden Daten-URI als seinen eigenen eindeutigen Origin . Das bedeutet, dass die in einem Daten-URI eingeschlossenen Skripts in einem HTML-Dokument nicht auf Daten auf anderen Seiten zugreifen können. Außer in Firefox.

Firefox behandelt Daten-URIs etwas anders als alle anderen Browser. Darin enthalten die Daten-URIs vererben den Ursprung des Dokuments, das gerade geöffnet wird. Das bedeutet, dass alle Skripte auf die Daten des referenzierten Dokuments zugreifen können. Und das ist XSS für Sie.

15
jupenur

Ein XSS ist unter # 1 nicht möglich

Der schlimmste Fall, den ich mir vorstellen kann, ist, dass jemand dies für Social Engineering verwendet (sagen wir, dass Ihre Domain wirklich beliebt ist wie Ebay oder Amazon). Was ein Angreifer tun könnte, ist die Erstellung einer Nachricht, die etwa "Amazon/Ebay free stuff" für Sie enthält Gehen Sie zu http://haxor.site ", verwenden Sie die URL und senden Sie sie an jemanden.

Trotzdem finde ich es nicht gefährlich, weil die URL-Kodierung die Nachricht ziemlich unordentlich aussehen würde.

EDIT: Dies nur Antwort # 1, da, als ich diese Frage beantwortete, kein "# 2"

1
Jhuliano Moreno
var value = getQueryString('url'); 

window.location.href = encodeURI(value);

Ich denke, das ist der einfachste Weg

0
wushang