EN

Cross-Site-Scripting (XSS) und Schutz vor Angriffen

In diesem Artikel:

Cross-Site-Scripting, auch bekannt als XSS, ist eine der Web-Schwachstellen in der OWASP TOP 10-Liste.



Was ist XSS in der Cybersicherheit?

XSS ist eine der häufigsten JavaScript-Schwachstellen. Erfahren Sie hier, wie Sie XSS-Schwachstellen effizient beheben können.

Die Zahl der schwerwiegenden Sicherheitslücken in Webanwendungen nimmt jedes Jahr zu. Oft müssen sich Entwickler auch mit Sicherheitslücken auseinandersetzen, die sie noch nie gesehen haben. Diese Zero-Day-Angriffe sind der Grund, warum Entwicklungsteams proaktiv nach Schwachstellen in ihren Webanwendungen suchen müssen, bevor sie neue Funktionen für die Öffentlichkeit freigeben.

Erfahren Sie hier, wie Sie XSS-Schwachstellen effizient beheben können.

Was ist ein XSS-Angriff?

Unter Cross-Site-Scripting (XSS) versteht man das Einschleusen von clientseitigen Skripten in Webanwendungen, was durch eine fehlende Validierung und korrekte Kodierung von Benutzereingaben ermöglicht wird. Die schadhaften Skripte werden dadurch im Browser des Endbenutzers ausgeführt und ermöglichen verschiedene Angriffe, vom Diebstahl der Sitzung bis hin zur Überwachung und Änderung aller Aktionen, die der Endbenutzer auf der betroffenen Website durchführt. Dies ist immer dann möglich, wenn die Benutzereingaben (z. B. auf einer Website) weder auf der Client- noch auf der Serverseite ausreichend validiert sind.

Dies schließt die Änderung aller Benutzeraktionen auf dieser Website ein, da der Browser nicht weiß, dass dieses Skript nicht vertrauenswürdig ist. Da dieses Skript vertrauenswürdig ist, kann es z. B. auf Cookies oder Sitzungs-Tokens zugreifen oder sogar den Inhalt einer HTML-Seite verändern.

Es kann dauerhaft oder nicht dauerhaft eingeschleust werden, je nachdem, welche Art von XSS verwendet wird. Übliche Einfallstore für Cross-Site-Scripting-Angriffe sind Suchformulare, Foren oder Kommentarabschnitte.

Cross-Site Scripting
What is XSS vulnerabilty

XSS-Sicherheitsbewertungsstufe

Security Assessment Cross-Site Scripting XSS vulnerability level

CVSS-Vektor: AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Arten von Cross-Site Scripting (XSS)

Es gibt verschiedene Arten von XSS-Angriffen, bei denen unterschieden wird, ob die schadhaften Skripte auf nicht-persistente oder persistente Weise eingeschleust werden können. Außerdem wird unterschieden, ob die Schwachstelle durch eine fehlerhafte Eingabevalidierung auf der Client- oder Serverseite verursacht wird.

Es gibt 3 Haupttypen von Cross-Site-Scripting-Angriffen:

  • Gespeicherte XSS
  • Reflektiertes XSS
  • DOM-basiertes XSS

Gespeichertes (persistentes) Cross-Site-Scripting

Eine Stored Cross-Site Scripting-Schwachstelle ermöglicht es einem Angreifer, ein schadhaftes Skript dauerhaft in eine Webanwendung einzuschleusen.

In einem Stored XSS-Beispiel könnte das Skript über ein Eingabefeld an den Webserver übermittelt worden sein, der keine ausreichende Validierung durchgeführt hat und das Skript dauerhaft in der Datenbank speichert. Dies könnte zur Folge haben, dass dieses Skript nun an alle Benutzer, die die Webanwendung besuchen, ausgeliefert wird und z. B. Zugriff auf die Sitzungscookies des Benutzers erlangen kann.

  • Das Skript wird dauerhaft in der Webanwendung gespeichert.
  • Benutzer, die die Anwendung nach der Infektion besuchen, rufen das Skript ab
  • Bösartiger Code nutzt Schwachstellen in der Webanwendung aus
  • Das Skript und der Angriff sind auf der Serverseite sichtbar (für den Besitzer der Anwendung)

Reflektiertes (nicht persistentes) Cross-Site-Scripting

Eine Reflektierter Cross-Site Scripting-Schwachstelle tritt auf, wenn dem Benutzer direkt eine nicht geprüfte Eingabe angezeigt wird.

In einem Reflected XSS-Beispiel wird die Eingabe eines Suchformulars auf der Seite reflektiert, um anzuzeigen, was der Suchbegriff war. Ein Angreifer kann eine URL erstellen, die schadhaften Code enthält, und diese URL über E-Mail oder soziale Medien verbreiten. Ein Benutzer, der auf diesen Link klickt, öffnet die (gültige) Webanwendung, die dann direkt den Schadcode im Browser des Benutzers ausführt.

  • Das Skript wird nicht in der Webanwendung gespeichert. 
  • Der schadhafte Code wird nur einem Benutzer angezeigt
  • Benutzer, die den Link öffnen, führen das Skript aus, wenn die Anwendung geöffnet wird
  • Das Skript und der Angriff sind auf der Serverseite (für den Besitzer der Anwendung) nicht unbedingt sichtbar.

DOM-basiertes Cross-Site-Scripting

DOM steht für Document Object Model und ist eine Schnittstelle zu Webseiten. Es handelt sich im Wesentlichen um eine API für die Seite, die es Programmen ermöglicht, den Inhalt, die Struktur und die Stile der Seite zu lesen und zu manipulieren.

Ein DOM-basierter XSS-Angriff kann auch dann erfolgreich ausgeführt werden, wenn der Server keinen bösartigen Code in die Webseite einbettet, indem er eine Schwachstelle in dem im Webbrowser ausgeführten JavaScript nutzt. Wenn beispielsweise das JavaScript auf der Client-Seite den DOM-Baum der Webseite auf der Grundlage eines Eingabefelds oder GET-Parameters ändert, ohne die Eingabe zu validieren, kann bösartiger Code ausgeführt werden.

  • Das Skript wird nicht in der Webanwendung gespeichert.
  • Schadhafter Code wird nur einem Benutzer angezeigt
  • Der schadhafte Code nutzt Schwachstellen im Browser auf der Benutzerseite aus.
  • Das Skript und der Angriff sind auf der Serverseite (für den Besitzer der Anwendung) nicht unbedingt sichtbar.

Risiko von XSS-Schwachstellen

Da ein Cross-Site-Scripting-Angriff den Browser des Benutzers infiziert, könnten Sie denken, dass er für Ihre Webanwendung ziemlich harmlos ist. Doch leider ist das Gegenteil der Fall:

Ein Angreifer könnte durch das eingeschleuste Skript Teile der Webseite verändern oder den Benutzer auf eine andere (potenziell bösartige) Webseite schicken. Ihr Benutzer wird dies bemerken und Ihre Webanwendung in der Zukunft wahrscheinlich meiden.

Es gibt einfache Möglichkeiten, das Risiko von Cross-Site-Scripting-Angriffen für Benutzer zu verringern, da Add-ons für einige Browser vor bestimmten Malware-Angriffen schützen. Als Anbieter der Anwendung sollten Sie sich jedoch nicht darauf verlassen, dass alle Ihre Nutzer über diese Add-ons verfügen, weshalb Sie selbst Maßnahmen ergreifen sollten.

XSS Prävention Guide

Leitfaden

Cross-Site-Scripting (XSS) ist einer der bekanntesten Injektionsangriffe. Erfahren Sie, wie Sie diese Angriffsart erkennen und verhindern können.

Mehr erfahren

Wie lassen sich XSS-Angriffe verhindern?

Cross-Site-Scripting-Schwachstellen sind schwer zu erkennen und zu beheben. Was können Sie also tun? Um XSS-Angriffe zu verhindern, sollten Sie alle Benutzereingaben als potenziell bösartig behandeln und einige Programmierrichtlinien befolgen:

Vermeiden Sie nicht vertrauenswürdige Eingaben

XSS-Angriffe treten nur auf, wenn Benutzereingaben auf der Webseite angezeigt werden. Versuchen Sie daher, die Anzeige von (nicht vertrauenswürdigen) Benutzereingaben nach Möglichkeit zu vermeiden. Wenn Sie Benutzerdaten anzeigen müssen, schränken Sie die Stellen ein, an denen die Benutzereingaben erscheinen könnten. Jede Eingabe, die innerhalb eines JavaScript-Tags oder einer auf der Website angezeigten URL angezeigt wird, ist viel wahrscheinlicher als eine Eingabe, die innerhalb eines div- oder span-Elements im HTML-Body erscheint.

Benutzereingaben filtern

Wenn eine nicht vertrauenswürdige Eingabe als normaler Text innerhalb eines HTML-Tags angezeigt wird, filtern Sie die Zeichen heraus, die es einem Angreifer ermöglichen, ein <script>-Tag auf der Seite einzufügen. Verwenden Sie dazu die folgenden Funktionen:

htmlspecialchars($input) # PHP
html.escape(input, quote=True) # Python
org.apache.commons.lang.StringEscapeUtils.escapeHtml(input) # Java

In JavaScript müssen Sie für diese Aufgabe eine eigene Funktion definieren. Sie können beispielsweise folgende Funktion verwenden:

function escapeHtml(text) {
  var map = {
    '&': '&amp;',
    '<': '&lt;',
    '>': '&gt;',
    '"': '&quot;',
    "'": '&#039;'
  };
 
  return text.replace(/[&<>"']/g, function(m) { return map[m]; });
}

Wenn Benutzereingaben in Tag-Attribute oder in ein Skript eingefügt werden sollen, müssen Sie stärkere Escape-Mechanismen verwenden. Weitere Informationen finden Sie im Cheat Sheet zur XSS-Prävention. Das ist der Fall, wenn Sie planen, Benutzereingaben in Fällen wie den folgenden zuzulassen:

<a href="http://example.org/search/q?...USER INPUT..."></div>
<script>alert('...USER INPUT...')</script>
<style> { property: ...BENUTZER-EINGABE...; } </style>

DOM-basiertes XSS beheben

Um einen DOM-basierten XSS-Angriff zu verhindern, können Sie eine sichere JavaScript-Eigenschaft wie ‚element.text content‘ für nicht vertrauenswürdige Benutzereingaben verwenden. Dadurch wird verhindert, dass der Browser den potenziellen JavaScript-Code innerhalb der „untrustedVariable“ rendert. Eines der Dom-XSS-Beispiele könnte wie der folgende Codeschnipsel aussehen:

element.textContent = untrustedVariable

Außerdem ist es wichtig, sichere JavaScript-Funktionen wie „inner text“ oder „text content“ anstelle von „innerHtml“ zu verwenden. Es ist immer gut, sich vor Augen zu halten, dass es gefährlich ist, benutzergesteuerte Eingaben ohne angemessene Bereinigung in Ihre Webanwendung zu übertragen.

Für weitere Informationen stellt OWASP ein spezielles DOM-basiertes XSS Prevention Cheat Sheet zur Verfügung, das einen zusätzlichen Satz von Regeln zum Schutz Ihrer Webanwendung vor DOM-basiertem XSS enthält.

Verwenden Sie ein XSS-Schwachstellen-Tool

Wie bereits erwähnt, sind XSS-Angriffe manchmal schwer zu erkennen. Dies kann jedoch geändert werden, wenn Sie sich externe Hilfe holen. Eine weitere Möglichkeit, XSS-Angriffen vorzubeugen, ist die Verwendung des XSS-Tools von Crashtest Security Suite – ein Web-Schwachstellen-Scanner mit einer 14-tägigen kostenlosen Testversion, mit dem Sie jede Schwachstelle finden können, der Sie ausgesetzt sein könnten. Manuelles Testen ist sehr zeit- und kostenaufwändig – und kann daher nicht für jede Iteration Ihrer Webanwendung durchgeführt werden.

Aus diesem Grund sollte Ihr Code vor der Veröffentlichung nicht ungetestet bleiben.

Mit automatisierten Sicherheitstests können Sie Ihre Webanwendung vor jeder Veröffentlichung auf Cross-Site Scripting und andere kritische Schwachstellen überprüfen. Auf diese Weise können Sie sicherstellen, dass die Live-Version Ihrer Webanwendung immer noch sicher ist, wenn Sie eine Funktion ändern oder hinzufügen.

Aktivieren Sie Content Security Policy (CSP)

Dies kann nicht nur Cross-Site-Scripting-Angriffe, sondern auch Cross-Site-Injection-Angriffe verhindern.

Lesen Sie unseren Leitfaden zur Vermeidung von XSS-Schwachstellen

Häufig gestellte Fragen

Welches sind die häufigsten Angriffe mit XSS?

  • Kontrolle über den Computer des Opfers
  • Ersetzen von DOM-Knoten
  • ATO (Kontoübernahme)
  • Cookie-Grabber

Welche Auswirkungen hat Cross-Site-Scripting?

Bei Reflected XSS und DOM-basiertem XSS sind die Auswirkungen mäßig. Bei gespeichertem XSS werden die Auswirkungen als schwerwiegend eingestuft.

Ist XSS wirklich ein Problem?

Ja. Es ist sehr wichtig, dass Sie verstehen, wie XSS funktioniert und welche Risiken es für Ihr Unternehmen birgt. Es gibt viele Beispiele für Unternehmen, die aufgrund von XSS-Problemen gehackt wurden. Einige dieser Beispiele sind:

  • Paypal
  • Twitter
  • Facebook
  • Yahoo
  • Microsoft
  • Google

Ist XSS verbreiteter als SQLi?Ja, XSS ist weitaus verbreiteter als SQLi. Das liegt an der Art der XSS-Angriffe. Sie sind leichter auszuführen und werden von automatischen Scannern seltener entdeckt.

Testen Sie unseren XSS-Scanner kostenlos

Erhalten Sie jetzt kostenlos einen schnellen Sicherheitsbericht für Ihre Website

Wir analysieren derzeit http://example.com
Wir scannen derzeit http://example.com
Status des Scans: In Bearbeitung
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Datum: 27/05/2022
Crashtest Security Suite prüft auf:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Scanauftrag ausfüllen
Bitte geben Sie Ihre Daten ein, um die schnelle Sicherheitsüberprüfung zu erhalten.
Ein Sicherheitsspezialist analysiert gerade Ihren Scan-Bericht.
Bitte geben Sie Ihre Telefon-/Handynummer an, damit wir Ihre Identität überprüfen können:
Ihren Bericht anfordern
Vielen Dank.
Wir haben Ihren Antrag erhalten.
Sobald Ihr Sicherheitsaudit fertig ist, werden wir Sie benachrichtigen.