Cross-Site Scripting

Aus Siwecos
Wechseln zu: Navigation, Suche

Cross-Site Scripting


Bildquelle: pixabay.com

Cross-Site Scripting wird mit XSS abgekürzt, weil die Abkürzung CSS schon für Cascading Style Sheets besetzt war. Da Cross Kreuz bedeutet hat man als Ersatz einfach das X gewählt und daraus entstand dann XSS als geläufige Abkürzung für Cross-Site Scripting.

XSS bedeutet webseitenübergreifendes Skripting (meist JavaScript) und tritt auf, wenn eine Webanwendung Daten eines Nutzers ohne Prüfung annimmt und diese Daten dann an einen Browser weitersendet. Unter Ausnutzung von Sicherheitslücken in Webanwendungen werden unsichere Nutzungsformen als vertrauensvoll dargestellt. Ziel ist u. a. an sensible Daten des Benutzers zu gelangen, um beispielsweise seine Benutzerkonten zu übernehmen (Identitätsdiebstahl). Dazu werden Webseiten mit clientseitigen Skripten infiziert, die von Nutzern aufgerufen werden.

XSS ist eine Art HTML Injection. Damit ist es einem Angreifer möglich, auch Skripte indirekt an den Browser des Opfers zu senden und damit bösartigen Code (malicious code) auf der Seite des Clients auszuführen. Häufige Anwendungsbereiche sind dynamisch erzeugte Webseiten wie Gästebücher, Foren und Kommentarfunktionen, aber auch die Kontrollausgabe von eingegebenen Bestellungen, Registrierungen oder Suchanfragen. Die Webseite könnte z. B. mit einem Code injiziert sein, der dazu dient, dem Benutzer ein Formular in einem iFrame anzuzeigen. Der Nutzer bemerkt nicht, dass das Formular nicht zur Webseite gehört, lässt sich also täuschen und füllt es aus.

Auf diese Weise können Hacker Daten abgreifen, die zwischen dem Benutzer und der infizierten Webseite ausgetauscht werden. Je nach Sensibilität der gewonnenen Daten können die Folgen kleinere Ärgernisse oder auch große Sicherheitsrisiken sein. Wenn in einem solchen Formular beispielsweise Authentifizierungsinformationen abgefragt werden, ist das ein großes Sicherheitsrisiko.

Über injizierten Code könnte der Benutzer auch auf eine manipulierte Webseite weitergeleitet werden, die von einem Hacker kontrolliert wird. Die manipulierte Seite sieht genauso aus wie die Original-Webseite. Erfolgt darüber ein Login des Benutzers, kann der Angreifer diese Daten sammeln und missbrauchen.


Angriffsarten

Es wird zwischen drei grundlegenden Arten von Cross-Site-Scripting-Angriffen unterschieden: Es gibt reflektierte, persistente und DOM-basierte Angriffe.

Reflektiert oder nicht-persistent

Das nicht-persistente (non-persistent) oder reflektierte (reflected) Cross-Site-Scripting ist eine Angriffsart, bei welcher die Benutzereingabe direkt vom Server wieder zurückgesendet wird. Wenn in der Eingabe Skriptcode enthalten, der vom Browser des Benutzers anschließend interpretiert wird, kann dort Schadcode ausgeführt werden.

Bei dieser Angriffsart nutzt der Angreifer die Tatsache aus, dass dynamisch generierte Webseiten ihre Inhalte oft über Parameter (also bestimmte Eingabewerte) in der URL (HTTP-GET-Methode) oder bei Formularen (HTTP-POST-Methode) anpassen. Diese Art wird als "Nicht-persistent" bezeichnet, weil der der Schadcode nur temporär bei der jeweiligen Generierung der Webseite eingeschleust, aber nicht gespeichert wird. Ruft man die Seite ohne die manipulierte URL oder das manipulierte Formular auf (also ohne bestimmte Parameter bzw. Eingabewerte), ist der Schadcode nicht mehr enthalten.

Persistent oder beständig

Im Unterschied zum nicht-persistenten (non-persistent) oder reflektierten (reflected) Cross-Site-Scripting wird beim persistenten (persistent) oder beständigen (stored) Cross-Site-Scripting der Schadcode auf dem Webserver gespeichert, wodurch er bei jeder Anfrage ausgeliefert wird.

DOM-basiert oder lokal

Beim DOM-basierten (DOM Injection) oder lokalen (local) Cross-Site-Scripting ist die Webapplikation auf dem Server nicht beteiligt, wodurch auch statische HTML-Seiten mit integriertem JavaScript anfällig sind. Bei dieser Variante wird der Schadcode zur Ausführung direkt an ein clientseitiges Skript übergeben. Denkbar wäre ein JavaScript, welches einen URL-Argumentwert zur Ausgabe von Daten verwendet, ohne diesen ausreichend zu prüfen. Für einen solchen Angriff muss gezielt eine kompromittierten URL aufgerufen werden.


Wie können Sie sich schützen?


Benutzer:
  • Durch Ausschalten der JavaScript-Unterstützung im Browser kann man sich gegen clientseitige XSS-Angriffe schützen.
  • Für einige Browser gibt es Addons, die mögliche XSS-Angriffe erkennen und verhindern.



Webseiten-Betreiber:
  • Für jeden Webseitenbetreiber ist es unumgänglich, alle eingehenden Eingabewerte als unsicher zu betrachten und vor der weiteren Verarbeitung auf der Serverseite zu überprüfen.



Weiterführende Links zum Thema XSS