Cross-Site-Scripting Begriffserklärung und Definition

Cross-Site-Scripting wird ins Deutsche mit weibseitenübergreifendem Scripting übersetzt. Cross-Site-Scripting bezeichnet die Ausnutzung einer Sicherheitslücke an Computern in Webanwendungen. Hier werden Informationen aus Kontexten, in denen sie als nicht vertrauenswürdig eingestuft werden, in andere Kontexte hinzugefügt. Das geschieht, indem sie durch das Cross-Site-Scripting als vertrauenswürdig eingestuft werden. Das hat zur Folge, dass nun aus den vertrauenswürdigen Kontexten Angriffe gestartet werden können.

Meistens haben diese Angriffe das Ziel, die sensiblen Daten von Nutzern zu erhalten. Das ist beispielsweise beim Identitätsdiebstahl der Fall. Hierbei werden die Benutzerkonten von einem Nutzer übernommen. Das Cross-Site-Tracing ist eine spezielle Anwendungsform des Cross-Site-Scriptings.

Cross-Site-Scripting: Die Terminologie

Cross-Site-Scripting wird als ein Angriff verstanden, der zwischen verschiedenen Aufrufen von einer Webseite gestartet wird. Das Cross-Site-Scripting bezieht sich jedoch zumeist nicht darauf, dass hierbei verschiedene Webseiten beteiligt sind. In der Regel werden für das Cross-Site-Scripting die am weitesten verbreiteten Script-Sprachen genutzt. Insbesondere JavaScript kommt hier zum Einsatz. Daher wird das Scripting zu dem Cross Site hinzugefügt.

Im Englischen wird das X als eine Abkürzung für das Kreuz, also Cross verwendet. Das Cross-Site-Scripting hat trotz der Ähnlichkeit der Namen zur Cross-Site-Authentication-Attacke, der Cross-Site-Request-Forgery oder dem Cross-Site-Cooking keine Gemeinsamkeiten mit diesen Anwendungen.

Die Funktionsweise des Cross-Site-Request-Forgerys

Cross-Site-Scripting kann als eine Art HTML Injektion angesehen werden. Nimmt eine Webanwendung die Daten von einem Nutzer an, dann tritt das Cross-Site-Scripting auf. Das Cross-Site-Scripting ist erst dann vollendet, wenn diese Daten im Anschluss daran an einen Browser weitergesendet werden, ohne dass der Inhalt der Daten des Nutzers überprüft wird. So können mögliche Angreifer indirekt die Skripte an die Browser der Opfer senden. So kann der Schadcode auf der Seite der Clients ausgeführt werden.

Ein Beispiel für das Cross-Site-Scripting ist die Parameterübergabe an serverseitige Skripte. Diese Skripte erzeugen eine dynamische Webseite. Eine solche dynamische Webseite kann beispielsweise ein Eingabeformular auf einer Webseite sein, wie es in Webshops, Blog, Wikis oder Foren üblich ist. Diese nun eingegebenen Daten werden nun erneut auf der Webseite als Seiteninhalt dargeboten, sobald die Site durch Benutzer aufgerufen wird. Dadurch können manipulierte Daten an alle Nutzer gesendet werden, wenn das nicht durch das Serverscript verhindert wird. Solche Daten werden häufig der Code von einer dienstseitigen Skriptsprache, zumeist handelt es sich hierbei um JavaScript.

Verschiedene Angriffsarten

Angriffsarten, die häufig genutzt werden, sind Webseite-Defacements, das Entführen der Benutzer-Sessions, Phishing-Angriffe, die Kontrollübernahme des Benutzerbrowsers oder das Einstellen von negativen Inhalten. Solche Angriffe sind insbesondere dann besonders gefährlich, wenn die Webseite, auf welcher der Schadcode platziert wurde, im lokalen Browser durch besondere Sicherheitsrechte, also durch Privilegien ausgestattet wurde. Hier ist der Schadcode in der Lage je nach der Mächtigkeit von der Skriptsprache, verschiedene Dinge zu tun, welche nur mit den Rechten von den lokalen Benutzern möglich sind.

Viele lokale Benutzer besitzen aus Gründen der Bequemlichkeit auf den Microsoft-Windows-Systemen die Administrator-Rechte. Das ist bereits eine gefährliche Konstellation. Jedoch ist es auch ohne die Administrator-Rechte möglich, dass ein Angreifer die Sicherheitslücken ausnutzt und so bei der Ausführung der Skriptsprache die benötigten Rechte erhält. Allerdings wird das Cross-Site-Scripting beispielsweise in Foren weit gestreut und richtet sich nicht gezielt an bestimmte Personen. Allerdings ist das Cross-Site-Scripting auch dann möglich, wenn es sich an eine ausgewählte Person richtet.

Nicht nur das klassische Cross-Site-Scripting interpretiert die Scriptcodes, sondern das tun häufig auch gängige E-Mail-Programme. Das wiederum ermöglicht einen Angriff über E-Mails. Hier wird durch den Angreifer ein zuvor durch ihn präpariertes HTML-Dokument an das Opfer per E-Mail versendet. Eine andere Möglichkeit besteht darin, dem Opfer einen Hyperlink zukommen zu lassen. Dieser Hyperlink kann entweder auf eine Webseite verweisen, die vom Angreifer präpariert wurde oder auch selbst einen Schadcode enthalten.

Häufig werden beim Cross-Site-Scripting kurze ULS, Techniken des URL-Spoofing oder auch andere Verfahren der Codierung genutzt, um so den echten Link zu verschleiern oder um den versendeten oder genutzten Link vertrauenswürdig wirken zu lassen.

In jüngster Vergangenheit kam es dazu, dass auch Webspider für das Cross-Site-Scripting missbraucht wurden. Mit dieser Methode sind aber auch Attacken über eine SQL-Injection möglich. Hierzu muss lediglich ein Link, der zuvor präpariert wurde, auf eine Webseite gestellt werden. Wird dieser Link durch einen Webspider angeklickt, wird hierdurch die Attacke ausgelöst. Wird der Linkadresse gefolgt, taucht die IP-Adresse von dem Spider auf. Die des eigentlichen Angreifers erscheint folglich nicht in den Protokollen von dem angegriffenen System. Somit hat der Angreifer die Möglichkeit, anonym vorzugehen. Allerdings besteht theoretisch die Möglichkeit, in besonders schweren Fällen die IP-Adresse von dem Computer, von welchem der Angriff gestartet wurde, herauszufinden.

Der Schutz vor Cross-Site-Scripting

Zum einen können die Betreiber von Websites Schutzmaßnahmen gegen das Cross-Site-Scripting einleiten. Damit bei einer Webanwendung keinerlei Basis für die Cross-Site-Scripting Angriffe geboten werden, müssen die eingehenden Eingabewerte allesamt als unsicher betrachtet werden. Bevor diese auf dem Server weiter verwertet werden, müssen sie geprüft werden.

Ein Betreiber von einer Webanwendung sollte sich hierbei nicht auf die Schwarze Liste verlassen, da er die genauen Methoden des Cross-Site-Scriptings nicht kennt. Es kann genauer vorgegangen werden, indem die Eingaben der weißen Liste genau definiert werden und nur diese Eingaben zugelassen werden. Diese Methode zählt zu den Best Practices innerhalb der Programmierung und sollte nach Möglichkeit angewendet werden.

Eine DOM-Injektion kann weniger einfach verhindert werden. Diese Benutzereingaben können nicht serverseitig geprüft werden. Ein solcher Angriff findet immer unter der Umgehung der Server statt. Hier muss die Prüfung der Gültigkeit für die Eingabedaten auf der Seite der Clients im Webbrowser erfolgen. Das jedoch ist leicht zu manipulieren. Bei reflektiertem und persistentem Cross-Site-Scripting kann eine Ausgabe abgesichert werden, indem die HTML-Metazeichen durch die entsprechenden Zeichenreferenzen ersetzt werden. So werden diese als normale Zeichen erkannt und behandelt und nicht als Metazeichen.

Metazeichen

Wird die Ausgabe als ein Teil von einer URL gestaltet, so muss die Codierung der URL in Bezug auf die Eingabewerte zur Anwendung kommen. Erfolgt die Ausgabe über einen JavaScript-Code, so müssen die verwendeten Zeichen mit einem Schrägstrich, der umgekehrt ist, maskiert werden. Die drei Kontexte, also HTML, URL und JavaScript haben unterschiedliche Zeichen und jeweils eine Metafunktion. Der umgekehrte Schrägstrich ist beispielsweise für HTML überhaupt kein Metazeichen. So müssen die Zeichen immer an die Codierung im Ausgabemedium angepasst werden.

Bei den meisten Skript- oder Programmiersprachen gibt es bereits vordefinierte Funktionen, welche die Metazeichen ersetzen. Diese vordefinierten Funktionen sollten den eigenen Verfahren immer vorgezogen werden. Selbst entwickelte Inhaltsprüfungen sind in der Regel weniger gut getestet und auch weniger ausgereift. In den einzelnen Programmiersprachen gibt es hierzu vielfältige Lösungsmöglichkeiten. Sie folgen jedoch stets einem ähnlichen Prinzip. Die Zeichen, die in Java problematisch sind, können maskiert oder ersetzt werden. In PHP oder Perl gibt es entsprechende Funktionen, die zur Verfügung stehen, um problematische HTML-Zeichen zu maskieren. Durch den Einsatz von WAFs, also den Web Application Firewalls, können zumindest theoretisch einfache, also primitive Cross-Site-Scripting Attacken unterbunden werden.

Angriffe verhindern

Die Webseitenutzer können sich durch das Ausschalten der Unterstützung durch JavaScript – also das Active Scripting im Browser – gegen Cross-Site-Scripting Angriffe schützen. Einige Webbrowser bieten Angriffsvektoren, die jedoch nur für „echtes“ Cross-Site-Scripting gelten, also für ein solches, das mit JavaScript arbeitet. Wird lediglich eine HTML-Injektion verwendet, schützt das Abschalten des Active Scripting nicht. Durch einige Anwendungen werden Erweiterungen angeboten, die mögliche Cross-Site-Scripting Angriffe erkennen und verhindern können.

Zusammenfassung

Cross-Site-Scripting (XSS) ist eine weitverbreitete Sicherheitslücke in Webanwendungen, die das Einschleusen von schädlichem Code, meist in Form von JavaScript, ermöglicht. Ziel ist häufig der Diebstahl sensibler Nutzerdaten oder die Kontrolle über Benutzerkonten. Der Angriff wird meist zwischen den Aufrufen einer einzelnen Webseite ausgeführt und nutzt die Schwäche der Webanwendung, Eingabewerte nicht ausreichend zu prüfen.

Es gibt unterschiedliche Angriffsarten wie Phishing, Session-Hijacking und Webseiten-Defacements. Die Gefahr erhöht sich, wenn Nutzer über erweiterte Sicherheitsprivilegien im Browser verfügen oder Administratorenrechte auf ihrem System haben. Auch E-Mail-Programme und Webspider können für solche Angriffe missbraucht werden.

Zum Schutz vor XSS-Angriffen sollten Webseitenbetreiber sämtliche Eingabewerte als potenziell gefährlich betrachten und entsprechende Prüfmechanismen implementieren. Sicherheitsmaßnahmen wie Web Application Firewalls (WAFs) und das Deaktivieren von JavaScript im Browser können ebenfalls hilfreich sein, bieten jedoch keinen umfassenden Schutz.

Häufige Fragen und Antworten