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 Websites.
Hackerangriffe kann man gut mit einem Einbruch vergleichen. Brute Force Attacken ähneln dabei eher der Methode Brecheisen. Kriminelle stemmen sich so lange gegen das Werkzeug, bis die Tür oder das Fenster aufbricht. Angriffe auf XSS Schwachstellen hingegen sind ausgeklügelt: Es ist den Kriminellen genau bekannt, wo sie ansetzen müssen und verschaffen sich ganz gezielt Zugriff auf eine Website.
Im Zuge des Cross Site Scripting werden also Sicherheitslücken in Websites gezielt ausgenutzt. Hierbei werden schädliche Skripte in einen vertrauenswürdigen Kontext (deine Website!) eingeschleust. Ähnlich einem blinden Passagier auf einem Schiff nutzt dieser Schadcode deine Website als Vehikel, um seine eigenen Ziele zu verfolgen.
Im schlimmsten Fall werden so vertrauliche Informationen erhalten, oder auch 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 hat ein Grundprinzip
Cross Site Scripting funktioniert über das Grundprinzip, eine Lücke auszunutzen und Schadcode auf deine Website einzuschleusen. Es ist immer dann eine Gefahr, wenn eine Webanwendung eingegebene Daten ohne Überprüfung auf eventuell vorhandenen Skriptcode an den Webbrowser weiterleitet. Ein anschauliches Beispiel für so eine Webanwendung ist ein Supportchat.
Ü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 möglich, von außen HTML Code in die Metabeschreibungen von Bildern einzuschleusen. Jedes Gerät, auf dem nun das betroffene Bild näher angeschaut wurde (z.B. durch einen Klick auf das Bild), würde Gefahr laufen attackiert zu werden. So hätten unter anderem die Computer, auf denen dieses Bild angesehen wurde, mit einem Virus infiziert werden können.
„*“ zeigt erforderliche Felder an
Beliebter Trick beim Cross Site Scripting: Manipulierte Formulare
XSS kann es außerdem ermöglichen, harmlose durch manipulierte Formulare zu ersetzen. Diese Formulare sammeln dann die Daten der Opfer (auf deiner Website!). 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 in den häufigsten Fällen das Monetarisieren. Das heißt konkret, dass entweder Daten gestohlen und später verkauft werden, oder infizierte Websites in ein sogenanntes Botnet eingebunden werden, welches anschließend vermietet wird.
3 Arten von XSS
Cross Site Scripting Attacken lassen sich grob in drei Typen unterteilen:
- reflektiertes Cross Site Scripting
- persistentes Cross Site Scripting
- DOM-basiertes oder lokales Cross Site Scripting
Grob gesagt laufen XSS Attacken folgendermaßen ab: Schädlicher Code wird dort eingeschleust, wo Eingaben seitens des Clients erwartet werden (beispielsweise bei einer seiteninternen Suche). Als Teil der Antwort des Servers wird der Schadcode dann beim Client, also im Browser, ausgeführt. Und genau dort wird dann auch der jeweilige Schaden angerichtet, also etwa Daten gestohlen.
Reflektiertes Cross Site Scripting
Einige Eingaben, wie Suchanfragen, werden vom Server reflektiert. Das bedeutet, dass die Website beispielsweise nach der Eingabe von „Test“ im Suchfeld „Sie suchten nach Test“ ausgibt. Der eingegebene Text wird also Teil der Antwort des Servers.
Genau das wird geschickt ausgenutzt: Wird anstatt eines Suchbegriffs ein schädliches Skript an den Webserver gesendet, kann die Website 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 Website eingeschleust, aber nicht gespeichert.
Im Juli 2017 wurde im Plugin WP Statistics eine solche Schwachstelle gefunden (und am selben Tag 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 Website, wenn ein Admin zuvor auf einen entsprechend manipulierten Link geklickt hatte, gehackt werden.
Das funktioniert so: Es werden Links mit manipulierten Parametern an potenzielle Opfer gestreut. Ohne es zu wissen, schickt das Opfer 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 dieser massenhaft an potenzielle Opfer verteilt werden. 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 Userdaten serverseitig speichern und anschließend ohne Überprüfung oder Codierung ausgeben (unter anderem Foren). Besonders gefährlich kann diese Art von Scripting für hochfrequentierte Blogs und Foren werden, da sich die Schadsoftware hier durch die große Userzahl schnell verbreiten kann.
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 wird gerne genutzt und erlaubt es, einem ganz normalen Forenpost ein schädliches Skript hinzuzufügen (auf einfache Weise mithilfe eines Kommentars). 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. Jetzt könnten zum Beispiel betroffene Clients „ausspioniert“ werden oder zu einem Botnetz für weitere Attacken hinzugefügt werden.
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 war der Fall des genericon package. Das genericon package ist ein Iconset, das von vielen Plugins verwendet wird. Über eine HTML Datei in diesem Iconset war es möglich, entsprechenden Schadcode einzuschleusen.
Voraussetzung für eine DOM-basierte XSS Attacke ist allerdings, dass User eine manipulierte URL anklicken. Ü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 daher auch weniger wahrscheinlichen Angriffsart.
Beispiel: Die manipulierte URL wird angeklickt und schickt damit eine Anfrage an die Webapplikation. 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 Clients als Teil des Skripts interpretiert und ausgeführt. Die im Browser dargestellte Website wird somit verändert und User sehen nun – ohne es zu merken – die manipulierte Website.
Maßnahmen gegen Cross Site Scripting
Die besten Maßnahmen gegen Cross Site Scripting Attacken sind einfach umzusetzen. Stütze dich am besten auf regelmäßige Updates, Firewalls und Whitelists. In zweiter Linie kann auch die Ausgabe des Servers abgesichert werden.
Regelmäßige Updates
Die Schwachstellen, über die der Schadcode eingeschleust wird, befinden sich entweder im WordPress Core, in Plugins oder in Themes. Genau deswegen sind regelmäßige Updates all dieser Komponenten auch so wichtig. Denn in diesen Updates werden die Schwachstellen, die bis dato gefunden wurden, behoben.
Auch ergibt es Sinn regelmäßig die Details von Updates zu lesen, um ein Gefühl dafür zu bekommen, welche Sicherheitslücken über die Aktualisierungen regelmäßig geschlossen werden. Für die Wartungs- und Sicherheitsupdates des WordPress Core werden diese Informationen beispielsweise im WordPress Blog dokumentiert.
Firewalls und Whitelists gegen einfache XSS-Attacken
Eine weitere einfache Schutzmaßnahme vor XSS Attacken sind sogenannte Web Application Firewalls, oder WAF. Diese Firewalls sind das Herzstück großer Sicherheitsplugins und werden von dem jeweiligen Rechercheteam des Herstellers mit den neuesten Schwachstellen gefüttert. Eine WAF ist ganz allgemein ein Verfahren, das Webanwendungen vor Angriffen über das Hypertext Transfer Protocol (HTTP) schützt.
Auch diese Schutzmechanismen haben aber ihre Grenzen. Denn bei einigen XSS Attacken findet der Angriff über die Datenbank statt. Daher ist das Prüfen von Nutzereingaben auf Schadcode einer der zentralen Sicherungsmechanismen beim Kampf gegen XSS Attacken. Dabei wird etwa der Inhalt von Kommentaren auf verdächtige Zeichenfolgen gescannt und wenn nötig aussortiert.
Auch die Datenausgabe sollte abgesichert werden
Regelmäßige Updates schließen vorhandene XSS Sicherheitslücken und Firewalls sowie Whitelists versuchen Schadcode auszufiltern, bevor dieser den Webserver erreicht und die Website infizieren kann. Doch sollte auch die Datenausgabe entsprechend gesichert werden. Die meisten Programmier- und Skriptsprachen, wie PHP, Perl oder JavaScript, besitzen hierfür bereits vordefinierte Funktionen zur Zeichenersetzung bzw. -maskierung. Diese sorgen dafür, dass „problematische“ HTML Metazeichen wie <, > und & durch harmlose Zeichenreferenzen ersetzt werden. So wird verhindert, dass der Schadcode aktiv werden kann. Auch sollte der Code mithilfe von sogenannten sanitization libraries bereinigt werden. Hierfür wird ein Plugin auf dem Server installiert und zusätzlicher Code in den Quellcode deiner Website eingebunden. Der folgende Codeschnipsel sorgt dann zum Beispiel dafür, dass <class> zu den erlaubten Attributen hinzugefügt wird:
var sanitizer = new HtmlSanitizer();
sanitizer.AllowedAttributes.Add("class");
var sanitized = sanitizer.Sanitize(html);
Um dies umzusetzen, sind Programmierkenntnisse vonnöten. Diese Absicherung der Datenausgabe ist für jemanden mit diesen Kenntnissen einfach zu implementieren.
Ein gesundes Maß an Skepsis: So schützen sich User
Aber nicht nur die Website selbst, auch die Clients (also dein Webbrowser) sind von XSS Attacken betroffen. Viele XSS Angriffe lassen sich schon durch einen kritischen und vorsichtigen Umgang im Zusammenhang mit „fremden“ Links verhindern. Es gibt unter anderem die Möglichkeit, NoScript Addons zu verwenden. Diese verhindern das Ausführen von Skripten, also den schädlichen Codezeilen, die unter anderem Daten klauen.
Wer auf Nummer sicher gehen möchte, kann auch das clientseitige Cross Site Scripting einfach durch das Ausschalten der JavaScript Unterstützung im Browser abwenden. Denn ist dieses sogenannte Active Scripting deaktiviert, haben bestimmte Arten von XSS Attacken keine Chance mehr, da die schädlichen Anwendungen gar nicht erst gestartet werden. Allerdings „funktionieren“ die meisten modernen Websites dann nicht mehr richtig – oder im schlimmsten Falle gar nicht mehr. Hier gilt es also zwischen den Gesichtspunkten Sicherheit und Usability abzuwägen. Falls dich diese Option interessiert, findest du sie in deinen Browsereinstellungen.
Fazit
XSS Schwachstellen sind mitunter 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. Deine Website wird also gekapert und für andere Zwecke missbraucht. XSS ist also nicht ungefährlich, daher ist entsprechender Schutz wichtig.
Besonders häufig sind reflektiertes und persistentes XSS, da lokales Cross Site Scripting aufwändiger und schwieriger umzusetzen ist. Websites, die eingegebene Userdaten ohne Überprüfung auf eventuell 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 normales WordPress die Möglichkeit, sich vor diesen Angriffen zu schützen. Updates aller WordPress Komponenten sind unter anderem eine einfache, aber sehr wirksame Maßnahme. Wenn du deine Plugins und Themes aktuell hältst und eine WAF nutzt, hast du aber schon einen großen Schritt in die richtige Richtung getan. Wenn du zudem noch Whitelists für eingehenden und ausgehenden Code nutzt, hast du deine Website schon hervorragend abgesichert. Gerade die letzten beiden Maßnahmen sind jedoch nicht ohne Weiteres und ohne Programmierkenntnisse umsetzbar.
Im Vergleich zu den recht primitiven Brute Force Attacken sind die komplexeren XSS Angriffe leider noch relativ häufig erfolgreich. Allerdings gibt es deutlich weniger dieser sogenannten Complex Attacks, als es Brute Force Attacken auf WordPress Websites gibt. Dennoch solltest du es diesen Angriffen so schwer wie nur irgend möglich machen. Denn ein erfolgreicher Hack kostet nicht nur Zeit und Geld für die Entfernung der Skripte, sondern kann auch deine Position in Suchmaschinen gefährden.