Cross-Site-Scripting_XSS

Cross-Site-Scripting – Wie Hacker deine Seite kapern

Zuletzt aktualisiert am

XSS, SQL-Injection, XMLrpc – wenn ein WordPress Sicherheitsupdate veröffentlicht wird, finden sich in den Updatereports vor allem kryptische Kürzel. Auch wenn klar ist, dass diese Updates nötig sind und das Plus an Sicherheit sehr erfreulich ist, ist es wichtig zu verstehen, was hinter diesen Sicherheitslücken steckt. Denn nur wenn du verstehst, welche Lücken die Updates schließen, kannst du auch eine informierte Entscheidung treffen. Daher widmen wir uns heute dem Cross-Site-Scripting, oder XSS, der mit Abstand häufigsten komplexen Attacke auf WordPress-Seiten.

Hackerangriffe kann man gut mit Einbrechern vergleichen. Brute Force Attacken ähneln dabei eher der Methode Brecheisen. Der Kriminelle stemmt sich so lange gegen das Werkzeug, bis die Tür oder das Fenster aufbricht. Angriffe auf XSS-Schwachstellen hingegen sind ausgeklügelt: Der Einbrecher weiß genau, wo er ansetzen muss und verschafft sich ganz gezielt Zugriff auf eine Seite.

Im Zuge des Cross-Site-Scripting werden also Sicherheitslücken in Websites gezielt ausgenutzt. Hacker schleusen hierbei schädliche Skripte in einen vertrauenswürdigen Kontext (deine Seiten!) ein. Ähnlich einem blinden Passagier auf einem Schiff nutzt dieser Schadcode deine Seite als Vehikel, um seine eigenen Ziele zu verfolgen.

Im schlimmsten Fall erlangen Angreifer so vertrauliche Informationen oder den Zugriff auf den Computer des geschädigten Users. Solche Attacken sind nicht gerade selten: Gut die Hälfte der vom Sicherheitsanbieter Wordfence 2015 und 2016 gefundenen Schwachstellen in Plugins waren Cross-Site-Scripting-Schwachstellen. Häufig bildet ein XSS-Angriff dann die “Basis” für weitere Attacken, wie zum Beispiel Spam-, Phishing- oder auch DDoS-Attacken. Deshalb zeige ich dir heute zum einen wie genau Cross-Site-Scripting funktioniert, welche Arten von Attacken es gibt und wie gefährlich die Angriffe sind.

Cross-Site-Scripting funktioniert immer ähnlich: über eine Lücke gelangt Schadcode auf deine Seite

Cross-Site-Scripting ist immer dann eine Gefahr, wenn eine Webanwendung eingegebene Nutzerdaten ohne Überprüfung auf eventuell vorhandenen Skriptcode an den Webbrowser weiterleitet. Ein gutes Beispiel für so eine Webanwendung ist ein Support-Chat.

Über die Webanwendung selbst können die schädlichen Skripte auf den Server gelangen. Von dort aus landet der Schadcode früher oder später dann bei den betroffenen Clients. Ein gutes Beispiel für eine solche XSS-Schwachstelle ist der im Juli 2016 entdeckte Bug in den Bildmetainfos in WooCommerce 2.6.2. Durch einen Fehler war es Angreifern möglich, von außen HTML-Code in die Metabeschreibungen von Bildern einzuschleusen. Jeder Kunde, der sich nun das betreffende Bild näher angeschaut hätte (z.B. durch einen Klick auf das Bild), würde Gefahr laufen attackiert zu werden. Ein Hacker hätte bspw. die Rechner deiner Kunden mit einem Virus infizieren können.

Beliebter Trick beim Cross-Site-Scripting: Manipulierte Formulare

XSS kann es Hackern außerdem ermöglichen, harmlose durch manipulierte Formulare zu ersetzen. Diese Formulare sammeln dann die Daten der Opfer (deiner Seitenbesucher!). Davor kann übrigens auch eine SSL-Verschlüsselung nicht schützen. Denn HTTPS bedeutet “nur”, dass die Verbindung zwischen Server und Client verschlüsselt wird. Ist allerdings das Formular selbst manipuliert, bringt auch eine verschlüsselte Verbindung nichts.

Wie bei anderen Angriffsarten auch, ist das Ziel von Hackern in den häufigsten Fällen das Monetarisieren ihrer Machenschaften. Das heißt konkret, dass Angreifer entweder Daten stehlen, die sie später verkaufen, oder Seiten infizieren möchten, um diese in ein sogenanntes Botnet einzubinden, das anschließend vermietet wird.

3 Arten von XSS: reflektiertes, persistentes und lokales XSS

Cross-Site-Scripting-Attacken lassen sich grob in drei Typen unterteilen:

Grob gesagt laufen XSS-Attacken folgendermaßen ab: Schädlicher Code wird dort, wo Nutzereingaben erwartet werden (bspw. bei einer seiteninternen Suche), eingeschleust. Als Teil der Antwort des Servers wird der Schadcode dann beim Client, also im Browser des Nutzers, ausgeführt. Und genau dort wird dann auch der jeweilige Schaden angerichtet, also bspw. Nutzerdaten gestohlen.

Reflektiertes Cross-Site-Scripting

Einige Eingaben, wie Suchanfragen, werden vom Server reflektiert. Das bedeutet, dass die Seite beispielsweise nach der Eingabe von “Test” im Suchfeld “Sie suchten nach Test” ausgibt. Das, was der User eingibt, wird also Teil der Antwort des Servers.

Genau das nutzen die Angreifer geschickt aus: Wird anstatt eines Suchbegriffs ein schädliches Skript an den Webserver gesendet, kann die Seite so manipuliert werden, dass sie diesen letztlich ausführt. Diese Angriffsart wird auch als nicht-persistent bezeichnet. Der Schadcode wird also lediglich temporär bei der jeweiligen Seite eingeschleust, aber nicht gespeichert.

Im Juli wurde im Plugin WP Statistics eine solche Schwachstelle gefunden (und am selbem Tage bereits behoben!). Ein Eingabewert auf der Seite ‚wps_visitors_page‘ wurde ungeprüft weitergeleitet, was zu einer Schwachstelle durch reflektiertes XSS führte. So konnte eine Seite, wenn ein Admin zuvor auf einen entsprechend manipulierten Link geklickt hatte, gehackt werden

So kann eine reflektierte Cross-Site-Scripting Attacke z. B. aussehen.
So kann eine reflektierte Cross-Site-Scripting Attacke z. B. aussehen.

Das funktioniert so: Der Angreifer streut Links mit manipulierten Parametern an seine potenziellen Opfer. Ohne es zu wissen, schickt der User mit dem Klick auf den Link einen “manipulierten” Request an den Server, und der Schadcode wird zusammen mit der Antwort des Servers ausgeführt. Da der Code – anders als beim persistenten XSS – nirgendwo gespeichert wird, muss der Hacker diesen massenhaft an potenzielle Opfer verteilen. Das kann zum Beispiel über Mails oder auch soziale Netzwerke passieren.

Persistentes Cross-Site-Scripting

Beim beständigen, oder persistenten, XSS werden die schädlichen Skripte auf dem Webserver gespeichert und bei jedem Aufruf durch einen Client ausgeliefert. Prädestiniert hierfür sind Webanwendungen, die Benutzerdaten serverseitig speichern und anschließend ohne Überprüfung oder Codierung ausgeben (bspw. Foren). Besonders gefährlich kann diese Scripting-Art für hochfrequentierte Blogs und Foren werden, da sich die Schadsoftware hier durch die große Anzahl an Nutzern schnell verbreiten kann.

Diese Grafik zeigt einen möglichen Ablauf einer persistenten Cross-Site-Scripting Attacke.
Ablauf einer persistenten Cross-Site-Scripting Attacke. Quelle: Blog SAP

Beispiel: In einem Forum werden gepostete Beiträge in einer Datenbank gespeichert. Dabei werden diese nicht selten ungeprüft und unverschlüsselt hinterlegt. Diese Chance machen sich Angreifer zunutze und fügen einem ganz normalen Forenpost ein schädliches Skript (z. B. mithilfe eines Kommentars) hinzu. Die User erhalten den jeweiligen Link zu dem Post entweder per Mail oder gelangen zufällig zu dem entsprechenden Eintrag und führen das Skript mit dem Aufruf des Posts aus. Vorteil für den Hacker: Er kann jetzt bspw. betroffene Clients “ausspionieren” oder sie zu seinem Botnetz für weitere Attacken hinzufügen.

DOM-basiertes bzw. lokales Cross-Site-Scripting

Anders als persistentes und reflektiertes XSS funktioniert das DOM (Document Object Model) basierte Cross-Site-Scripting durch die Ausführung von clientseitigen Skripten. Das heißt, dass der Server von einem solchen Angriff nichts mitbekommt und serverseitige Sicherheitsmaßnahmen auch nicht helfen.

Ein bekanntes Beispiel für eine solche Lücke ist der Fall des genericon package. Das genericon package ist ein Icon-Set, das von vielen Plugins, unter anderem auch von Jetpack, verwendet wird. Über eine HTML-Datei in diesem Icon-Set war es möglich entsprechenden Schadcode einzuschleusen.

Nach Eingabe dieser URL erschien ein javascript alert. Das ist der Beweis dafür, dass eingegebener javascript code genutzt werden konnte, um die jeweilige Seite zu manipulieren.
Nach Eingabe dieser URL erschien ein JavaScript Alert. Das ist der Beweis dafür, dass eingegebener JavaScript Code genutzt werden konnte, um die jeweilige Seite zu manipulieren. Quelle: securityaffairs.co

Voraussetzung für eine DOM-basierte XSS-Attacke ist allerdings, dass der User eine manipulierte URL anklickt. Über das Aufrufen dieser URL kann der Schadcode durch eine Lücke in einem clientseitigen Skript ausgeführt werden. Unter anderem die Tatsache, dass zunächst ein Link angeklickt werden muss, macht das DOM-basierte XSS zu einer etwas schwierigeren und somit auch weniger wahrscheinlichen Angriffsart.

Die Grafik zeigt einen möglichen Ablauf einer lokalen Cross-Site-Scripting Attacke.
Beispielhafter Ablauf einer lokalen Cross-Site-Scripting Attacke. Quelle: heise.de

Beispiel: Der User klickt die manipulierte URL an und schickt damit eine Anfrage an die Web-Applikation. Diese antwortet, indem der Skriptcode (der fehlerhaft, jedoch nicht manipuliert ist) an den Browser übergeben wird, um dort die Ausführung des Skripts zu starten. Die manipulierten Parameter aus der URL werden nun im Browser des Benutzers als Teil des Skriptes interpretiert und ausgeführt. Die im Browser dargestellte Webseite wird somit verändert und der Benutzer sieht nun – ohne es zu merken – die manipulierte Seite.

Fazit: Ziemlich häufig und nicht ungefährlich, daher ist entsprechender Schutz wichtig

XSS-Schwachstellen sind mit die häufigsten Einfallstore für Schadcode überhaupt. Und oft bildet ein entsprechender Angriff die Basis für weitere Attacken, wie Spam-, Phishing- oder auch DDoS-Attacken. Angreifer kapern hierbei also deine Seite und missbrauchen sie, um ihre eigenen Ziele zu erreichen.

Besonders häufig sind reflektiertes und persistentes XSS, da lokales Cross-Site-Scripting aufwändiger und schwieriger umzusetzen ist. Seiten, die eingegebene Nutzerdaten ohne Überprüfung auf evtl. vorhandenen Schadcode an den Webbrowser weiterleiten, sind besonders gefährdet. Solche Lücken zu finden, ist aber gar nicht so einfach. Im Prinzip ist genau das die Aufgabe von Sicherheitsanbietern, wie sucuri und Co, die laufend ihre Sicherheitsmaßnahmen weiterentwickeln.

Aber natürlich gibt es auch für normale WordPress-Nutzer die Möglichkeit sich vor diesen Angriffen zu schützen. Updates aller WordPress-Komponenten sind z. B. eine einfache aber sehr wirksame Maßnahme. Wie du als Seitenbetreiber, aber auch als Internetnutzer Cross-Site-Scripting verhindern kannst, erklären wir in unserem nächsten Artikel zu dem Thema.

Du hast noch Anmerkungen oder Fragen? Dann hinterlasse einfach einen Kommentar