Richtlinien

Injektion - XSS

Cross-Site Scripting, kurz XSS, ist eine weitere Form der Injection-Schwachstelle, bei der ein vom Angreifer kontrolliertes Skript im Browser eines anderen Benutzers ausgeführt wird. XSS kann auch als HTML/JavaScript-Injection-Schwachstelle betrachtet werden.

Die Auswirkungen einer XSS-Schwachstelle hängen stark vom Kontext ab, in dem sie auftritt. Sie reichen vom Auslesen von Informationen auf der Seite, auf der das Skript ausgeführt wird, bis hin zur Manipulation des Seitenstatus, um Aktionen im Namen des Opfers durchzuführen.

Sehen wir uns die verschiedenen Arten von XSS an, denen Sie begegnen können.

XSS-Arten

XSS lässt sich zur besseren Unterscheidung in verschiedene Kategorien einteilen. Diese basieren darauf, wie das Payload übermittelt wird und wo sich der Einstiegspunkt befindet.

Übermittlungsvektor des Payloads (Stored vs. Reflected)

Es gibt zwei Möglichkeiten, wie ein Angreifer ein XSS-Payload übermitteln kann:

  • Stored XSS: Über benutzergesteuerte Daten, die beispielsweise in einer Datenbank gespeichert und anderen Benutzern angezeigt werden.
  • Reflected XSS: Über ein vom Benutzer bereitgestelltes Payload, das in der URL/Query-String enthalten ist und vom Benutzer aufgerufen wird.

Der entscheidende Unterschied besteht darin, dass Reflected XSS in der Regel von einer Benutzerinteraktion abhängt und nur den Benutzer betrifft, der den Link mit dem schädlichen Payload öffnet. Stored XSS hingegen kann gegen einen oder mehrere Benutzer ausgeführt werden, indem einfach Seiten aufgerufen werden, die das Payload rendern.

Speicherort des Payloads (DOM vs. Non-DOM)

Der Ort, an dem ein Payload injiziert wird, bestimmt, ob die Schwachstelle als „DOM“-Schwachstelle eingestuft wird oder nicht. Dies bezieht sich auf den Unterschied, wo das Payload gerendert wird:

  • Non-DOM XSS: Das Payload wird innerhalb von HTML gerendert, sei es innerhalb eines Tags oder eines Attributs.
  • DOM XSS: Das Payload wird innerhalb von JavaScript gerendert, wie etwa in einem `<script>`-Tag oder einem Event-Handler wie `onclick=""`.

XSS – Abwehrprinzipien

In diesem Abschnitt betrachten wir die grundlegenden Prinzipien der XSS-Abwehr. Das Verständnis dieser Grundlagen ist essenziell, aber in der Praxis sollten Sie sich zu 99 % auf Ihre Templating-Bibliothek verlassen, um sich vor XSS zu schützen.

Wenn Sie Templates schreiben, die als Markup oder Code in einem Browser gerendert werden, ist *Encoding* der Schlüssel zum Schutz vor XSS. Encoding bedeutet in diesem Zusammenhang, eine Zeichenfolge in ein Format umzuwandeln, das vom Interpreter auf eine bestimmte Weise verarbeitet wird.

Die Art des Encodings hängt jedoch vom Ort oder Kontext ab, in dem die Daten verwendet werden.

  • Innerhalb eines Tags, wie `<div>Benutzereingabe hier</div>`: **HTML-Encoding**
  • Innerhalb eines Attributs, wie `<input placeholder="Benutzereingabe hier"></input>`: **Attribut-Encoding**
  • Innerhalb von JavaScript, wie `<script>x = "Benutzereingabe hier";</script>`: **JavaScript-Encoding**

Einige Frameworks verzichten auf Encoding als primäre Verteidigungsmaßnahme und nutzen stattdessen Sanitization, um Werte von Inhalten zu bereinigen, die gefährlich sein könnten. Dies ist ein weitaus komplexerer Prozess mit vielen Sonderfällen. Es wird nicht empfohlen, eigene Sanitization-Routinen zu implementieren.

Beispiele

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

C# – Unsicher: Razor

Wenn einem `IHtmlContent`-Objekt ein `@` vorangestellt wird, wird der Wert ohne jegliche Kodierung direkt in das Template eingefügt.

<!--- UNSICHER: Das htmlSnippet wird ohne Escaping interpretiert --->
@Html.Raw(htmlSnippet)

C# – Sicher: Razor

Standardmäßig wird jeder `string`, dem ein `@` vorangestellt ist, in Razor-Templates HTML-eskapiert.

<!--- SICHER: Das htmlSnippet wird HTML-eskapiert --->
@htmlSnippet

Java – Sicher: JSP

Bei der Verwendung von `c:out` erfolgt standardmäßig ein XML-Escaping (was über die Eigenschaft `escapeXml` geändert werden kann). Dies schützt vor XSS im HTML-Kontext, jedoch 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 Eingabe XML-eskapiert wird. Auch dies bietet nur Schutz im HTML-Kontext.

<div>${fn:escapeXml(author)}</div>

Javascript – Unsicher: Angular innerHtml

Durch die Angabe der `innerHTML`-Eigenschaft setzen Sie sich, wie der Name schon sagt, dem Risiko von XSS aus, da die Ausgabekodierung deaktiviert wird.

<!--- UNSICHER: Das htmlSnippet wird ohne Kodierung interpretiert --->
<p [innerHTML]="htmlSnippet"></p>

Javascript – Sicher: Angular Interpolation

Die Text-Interpolation von Angular mittels doppelter geschweifter Klammern (`{{` und `}}`) eskapiert die Ausgabe als HTML und schützt so vor XSS.

<!--- SICHER: Das htmlSnippet wird kodiert und anschließend interpretiert --->
<p>{{htmlSnippet}}</p>

Javascript – Unsicher: React dangerousInnerHtml

Die Verwendung der Eigenschaft `dangerouslySetInnerHTML` setzt Sie, wie der Name bereits andeutet, dem Risiko von XSS-Angriffen aus, da die Ausgabe-Kodierung deaktiviert wird.

<!--- UNSICHER: Wie der Name schon sagt, ist das Attribut dangerouslySetInnerHTML gefährlich, da es die Ausgabe nicht maskiert --->
<div dangerouslySetInnerHTML={{ __html: htmlSnippet }} />;

Javascript - Sicher: React-Interpolation

Die Text-Interpolation in React mittels geschweifter Klammern (`{` und `}`) maskiert die Ausgabe automatisch als HTML und schützt so vor XSS.

<!--- SICHER: Das htmlSnippet wird kodiert und anschließend interpretiert --->
<div>{htmlSnippet}</div>

Python - Unsicher: Django

Die Verwendung des `safe`-Filters in einem Django-Template deaktiviert die automatische Maskierung der Ausgabe und bietet somit keinen Schutz vor XSS.

<!--- UNSICHER: Das htmlSnippet wird nicht HTML-kodiert --->
<div>{{ htmlSnippet | safe }}</div>

Python - Sicher: Django

Die Text-Interpolation in Django mittels doppelter geschweifter Klammern (`{{` und `}}`) maskiert die Ausgabe automatisch als HTML und schützt so vor XSS.

<!--- SICHER: Das htmlSnippet wird HTML-kodiert --->
<div>{{ name }}</div>

‍

Slogan

Sichere Programmierung in der Praxis

Entdecken Sie Richtlinien für sicheres Programmieren, um Schwachstellen wie die OWASP Top 10 zu verstehen und zu beheben, und tauchen Sie in geführte Trainingsmissionen ein, um diese in realistischen Anwendungssimulationen zu üben.

Weitere Richtlinien
Demo buchen