指导方针

Injektion - XSS

Cross-Site Scripting, auch bekannt als XSS, ist eine weitere Art von Injection-Schwachstelle, die zur Auswertung eines vom Angreifer gesteuerten Skripts im Browser eines anderen Benutzers führt. XSS kann auch als HTML/JavaScript-Injection-Schwachstelle betrachtet werden.

Die Auswirkungen einer XSS-Sicherheitslücke hängen stark vom Kontext ab, in dem die Sicherheitsanfälligkeit besteht. Dies reicht von der Möglichkeit, Informationen von der Seite zu extrahieren, auf der das Skript ausgeführt wird, bis hin zur Bearbeitung des Seitenstatus, um Aktionen als Opfer auf der Seite auszuführen.

Schauen wir uns an, auf welche XSS-Typen Sie stoßen können.

XSS-Typen

XSS kann in mehrere Buckets aufgeteilt werden, um sie besser unterscheiden zu können. Sie werden danach kategorisiert, wie die Nutzlast geliefert wird und wo sich der Einstiegspunkt befindet.

Nutzlastliefervektor (gespeichert oder reflektiert)

Es gibt zwei Möglichkeiten, wie ein Angreifer eine XSS-Nutzlast bereitstellen kann:

Gespeichertes XSS: Durch benutzergesteuerte Daten, die beispielsweise in einer Datenbank gespeichert sind, in der die Daten für andere Benutzer gerendert werden
Reflektiertes XSS: Durch eine vom Benutzer bereitgestellte Nutzlast, die über die URL/Abfragezeichenfolge weitergeleitet wird, die von einem Benutzer aufgerufen wird

Der entscheidende Unterschied besteht darin, dass ein reflektiertes XSS in der Regel von der Benutzerinteraktion abhängt und sich nur auf den Benutzer auswirkt, der den Link mit der bösartigen Payload öffnet. Ein Stored XSS kann jedoch gegen einen oder mehrere Benutzer ausgeführt werden, indem einfach einige Seiten geöffnet werden, die die Payload rendern.

Standort der Nutzlast (DOM oder Nicht-DOM)

Der Ort, an den eine Nutzlast injiziert wird, bestimmt, ob Sie die Sicherheitsanfälligkeit als „DOM“ -Sicherheitslücke einstufen oder nicht. Dies bezieht sich auf den Unterschied zwischen dem Ort, an dem die Nutzlast gerendert wird:

Nicht-DOM XSS: Die Nutzlast wird in HTML gerendert, unabhängig davon, ob sie sich in einem Tag oder einem Attribut befindet
VON XSS: Die Nutzlast wird in JavaScript gerendert, wie ein <script>``-Tag oder ein Event-Handler wie `onclick=""`

XSS - Verteidigungsprimitive

In diesem Abschnitt werden die Prinzipien der Primitiven betrachtet, die der Verteidigung gegen XSS zugrunde liegen. Es ist wichtig, die Grundlagen zu verstehen, aber in der Praxis sollten Sie sich für 99% des Schutzes vor XSS auf Ihre Template-Bibliothek verlassen.

Wenn Sie Vorlagen schreiben, die in Markup oder Code gerendert werden, der in einem Browser ausgeführt wird, ist *Encoding* der Schlüssel zum Schutz vor XSS. Codieren bedeutet in diesem Zusammenhang, eine Folge von Zeichen zu nehmen und sie in ein Format umzuwandeln, das vom Interpreter auf eine bestimmte Weise verarbeitet wird.

Die Art der zu verwendenden Kodierung hängt jedoch vom Ort oder Kontext ab, in dem die Daten verwendet werden.

Innerhalb eines Tags, wie `<div>Benutzereingabe hier</div>`: **HTML-Kodierung**
Innerhalb eines Attributs, wie `<input placeholder="User input here"></input>`: **Attributkodierung**
In Javascript, wie `<script>x = „Benutzereingabe hier“;</script>`: **JavaScript-Kodierung**

Einige Frameworks verzichten auf die Kodierung als primäres Abwehrmittel und verwenden stattdessen eine Desinfektion, um einen Wert aus allen Inhalten zu entfernen, die gefährlich sein könnten. Dies ist ein viel komplexerer Prozess, bei dem es viele Randfälle zu berücksichtigen gilt. Es wird nicht empfohlen, eigene Desinfektionsroutinen zu implementieren.

Beispiele

Schauen wir uns einige Beispiele in verschiedenen Sprachen an, um zu sehen, wie das alles in Aktion aussieht.

C# - Unsicher: Razor

Wenn einem `IHTMLContent`-Objekt ein `@` vorangestellt wird, wird der Wert ohne Kodierung direkt in die Vorlage eingefügt.

@Html .Raw (HTML-Ausschnitt)

C# - Sicher: Razor

Standardmäßig ist jede `Zeichenkette`, der ein `@` vorangestellt ist, in Razor-Vorlagen mit HTML-Escape-Code.

@htmlSnippet

Java — Sicher: JSP

Wenn `c:out` verwendet wird, wird es standardmäßig XML-Escape verwendet (was mit der Eigenschaft `escapeXML` geändert werden kann), was in einem HTML-Kontext vor XSS schützt, aber nicht in anderen Kontexten.

<div><c:out value="<%= author %>" /></div>

Java - Sicher: (fnxml)

Ähnlich wie oben können Sie auch direkt `fn:escapeXML` aufrufen, wodurch die eingegebene Eingabe in XML maskiert wird. Das schützt auch nur in einem HTML-Kontext.

<div>$ {fn:escapeXML (Autor)}</div>

Javascript - Unsicher: Angular InnerHTML

Wenn Sie, wie der Name schon sagt, die Eigenschaft `innerHTML` angeben, sind Sie aufgrund der Deaktivierung der Ausgabekodierung dem XSS-Risiko ausgesetzt.

<p [innerHTML] ="htmlSnippet"></p>

Javascript - Sicher: Winkel interpoliert

Durch die Interpolation von Text in Angular mit doppelten geschweiften Klammern (`{{` und `}}`) wird HTML seiner Ausgabe entkommen und schützt so vor XSS.

<p>{{HtmlSnippet}}</p>

Javascript - Unsicher: React DangerousInnerHTML

Wenn Sie, wie der Name schon sagt, die Eigenschaft `dangerouslySetInnerHTML` angeben, sind Sie aufgrund der Deaktivierung der Ausgabekodierung dem XSS-Risiko ausgesetzt.

<div dangerouslySetInnerHTML= {{__html: htmlSnippet}} />;

Javascript - Sicher: Reagieren Sie interpoliert

Durch die Interpolation von Text in geschweiften Klammern (`{` und `}`) durch React wird HTML seiner Ausgabe entzogen und schützt so vor XSS.

<div>{Html-Snippet}</div>

Python - Unsicher: Django

Wenn man den `safe`-Filter in einem Django-Template verwendet, deaktiviert er das automatische Escaping der Ausgabe und schützt somit nicht vor XSS.

<div>{{HtmlSnippet | sicher}}</div>

Python - Sicher: Django

Djangos Interpolation von Text mit doppelten geschweiften Klammern (`{{` und `}}`) macht HTML aus seiner Ausgabe und schützt so vor XSS.

<div>{{name}}</div>

‍