© DrHitch/Shutterstock.com
JavaScript Security

3 Neue Angriffe in JavaScript


JavaScript lässt sich für viele schöne Zwecke einsetzen. Und für mindestens genau so viele unschöne. In diesem Kapitel geht es um zwei Themen: Zum einen um einige neue bzw. verbesserte Angriffe, die auf den Sicherheitskonferenzen vorgestellt wurden. Zum anderen um zwei Möglichkeiten, solchen Angriffen zu begegnen.

Fangen wir mit den Sicherheitskonferenzen an. Das Folgende ist eine willkürliche und keinesfalls repräsentative Auswahl von Vorträgen aus diesem und dem vergangenen Jahr. Für alle Vorträge war bei Weitem nicht genug Platz, also habe ich die ausgewählt, die mir hier am passendsten erschienen.

SVG – Nicht unbedingt nur eine Grafik

SVG steht zwar für „Scalable Vector Graphic“, ist aber weit mehr als nur ein weiteres Dateiformat für Bilder. SVG ist eine XML-basierte „Programmiersprache“ für Grafiken, und dass darüber auch XSS-Angriffe möglich sind, ist schon seit Langem bekannt [1]. Ein einfaches Beispiel dafür ist das folgende „Bild“:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg">
<script type="text/javascript">
alert("Kein SVG-Bild, sondern ein XSS-Angriff!")
</script>
</svg>

Auf der Sicherheitskonferenz Black Hat USA 2014 Anfang August hat Rennie deGraaf eine Reihe weitergehender Angriffe vorgestellt. Der Titel seines Vortrags, „SVG: Exploiting Browsers without Image Parsing Bugs“, macht auch gleich das grundlegende Problem dieser Angriffe deutlich: Es werden keine Fehler oder Schwachstellen ausgenutzt, sondern beabsichtigte Features der SVG-Spezifikation. SVG-Dateien dürfen nämlich HTML-, JavaScript- und CSS-Code enthalten und, dieser Code soll auch ausgewertet werden.

Es gilt also nicht die alte Atari-Ausrede „That’s not a bug, it’s a feature“, wenn mal wieder etwas nicht so funktioniert wie gedacht. Im Fall von SVG funktioniert alles genau so wie vorgesehen und trotzdem (oder besser: genau deshalb) sind die Angriffe möglich. Wenn Sie also den Benutzern Ihrer Webanwendung das Heraufladen von SVG-Dateien erlauben, müssen Sie diese sehr gründlich prüfen. Und zwar so, wie sie eine HTML-Datei prüfen würden, nicht nur wie eine Bilddatei. Theoretisch reicht es zwar, die SVG-Dateien als statische Bilder zu laden, da dann keine Skripte ausgeführt und keine externen Ressourcen geladen werden (siehe unten). In der Praxis funktioniert das aber nicht immer so wie vorgesehen.

Aus den von Rennie deGraaf vorgestellten Angriffen will ich hier nur ein konkretes Beispiel aufgreifen.

SVG-Datei mit XSS-Schwachstelle

Dass eine SVG-Datei von Anfang an XSS-Code enthalten kann, ist altbekannt. Aber hätten Sie damit gerechnet, dass eine SVG-Datei auch eine XSS-Schwachstelle enthalten kann, über die nachträglich Code eingeschleust werden kann? Ein Beispiel dafür zeigt Listing 3.1 (aus der Präsentation zu [2]).

<?php
header("Content-type: image/svg+xml");
echo "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>"
?>

<svg
xmlns="http://www.w3.org/2000/svg"
width="68"
height="68"
viewBox="-34 -34 68 68"
version="1.1">
<circle
cx="0"
cy="0"
r="24"
fill="<?php echo $_GET['colour']; ?>"/>
</svg>

Listing 3.1: SVG-„Bild“ mit XSS-Schwachstelle

Lassen Sie sich nicht davon täuschen, dass das Beispiel in PHP geschrieben ist, mit jeder anderen Programmiersprache wäre das genau so möglich. Das Problem besteht darin, dass die Farbe des gezeichneten Kreises ohne vorherige Prüfung aus der GET-Variable colour übernommen wird. Also eine ganz klassische XSS-Schwachstelle, wie man sie so oder so ähnlich immer wieder mal findet – nur eben normalerweise im HTML-Teil der Website und nicht in einem „Bild“. Wird das Skript mit einem Farbnamen für den Parameter colour aufgerufen, zum Beispiel blue, wird ein Kreis in dieser Farbe gezeichnet (Abb. 3.1). Wird es als svg-xss.php?colour="/><script>alert("XSS!");</script> aufgerufen, öffnet sich die Alertbox (Abb. 3.2).

eilers_javascript_1.png

Abbildung 3.1: „svg-xss.php?colour=blue“ – alles funktioniert wie gewünscht

eilers_javascript_2.png

Abbildung 3.2: „svg-xss.php?colour="/><script>alert("XSS!");</script>“ – die Alertbox sollte da nicht sein

Das ist zugegebenermaßen ein sehr konstruiertes Beispiel. Aber ist es wirklich so abwegig, dass SVG-Grafiken mit Parametern aufgerufen werden, um sie zu konfigurieren? Und wenn diese SVG-Dateien dann einzeln im Browser mit passend gesetzten Parametern aufgerufen werden, ist darüber durchaus ein Angriff möglich. Wie wäre es zum Beispiel mit einem Phishing-Angriff? Würde im obigen Beispiel anstatt die Alertbox zu öffnen ein nachgeahmtes Login-Formular der Website angezeigt, würde ein Benutzer das gewohnte Login-Formular unter der gewohnten Domain sehen. Und sich sehr wahrscheinlich einloggen und damit seine Zugangsdaten den Phishern zum Fraß vorwerfen.

Das Sicherheitsmodell von SVG

Aber kommen wir zurück zu Angriffen, bei denen über die SVG-Datei XSS-Code in eine Website eingeschleust werden soll. Zum Glück gibt es das Sicherheitsmodell von SVG. Werden SVG-Dateien als statische Bilder geladen, werden sie genauso wie alle anderen Bildformate behandelt: Externe Ressourcen wie Style Sheets, Skripte und andere Bilder werden nicht geladen, Skripte werden nicht ausgeführt, lediglich interne Style Sheets und data-URIs sind erlaubt.

Nur wenn SVGs als verschachtelte Dokumente geladen werden, werden sie genauso wie HTML-Code verarbeitet: Externe Ressourcen werden geladen, Skripte werden ausgeführt, die Same-Origin Policy wird beachtet, in IFrames mit sandbox-Attribut werden die Skripte nicht ausgeführt. Zumindest gilt das in der Theorie, denn in der Praxis wird das Sicherheitsmodell nicht überall beachtet. Zum Beispiel lädt der Internet Explorer externe CSS- und Bilddateien immer.

Als eine weitere mögliche Lösung des Problems neben der Prüfung der SVG-Dateien auf unerwünschte Inhalte bietet sich die Content Security Policy an, auf die ich unten eingehen werde. Kommen wir jetzt zu den nächsten Forschungsergebnissen.

Server über XSS kompromittieren

Oft hört man, XSS sei ja ziemlich harmlos. Damit kann man höchstens den Benutzer ärgern oder beispielsweise seine Zugangsdaten/Session-Cookies ausspähen, dem Server und den darauf gespeicherten Daten kann ja nichts passieren. Mal abgesehen davon, dass mit diesen Angriffen auf den Benutzer schon reichlich Schaden angerichtet werden kann, ist das alles ein gewaltiger Trugschluss. Ich habe schon 2009 auf der IPC einige XSS-Angriffe vorgestellt, über die der Server kompromittiert wurde [3]. Und zwar keine konstruierten Beispiele, sondern „in the wild“ entdeckte Angriffe.

Auf der Sicherheitskonferenz „Hack in the Box“ Amsterdam 2014 hat Hans-Michael Varbaek im Mai mehrere aktuelle Angriffe dieser Art vorgeführt [4]. Als Opfer dienten ihm PHP-Skripte, sodass ich darauf hier nicht näher eingehe. Da diese Angriffe aber auch auf Webanwendungen in jeder anderen Sprache übertragbar sind, sollten Sie sich nicht in Sicherheit wiegen, nur weil Sie zum Beispiel ASP.NET verwenden. Denn das Grundkonzept ist recht einfach: Über eine XSS-Schwachstelle wird JavaScript-Code eingeschleust, der beim Aufruf durch einen privilegierten Benutzer wie den Administrator oder einen Moderator entweder dessen Session-Identifier ausspäht oder direkt Aktionen in dessen Namen ausführt. Das kann etwa das Hinzufügen eines neuen privilegierten Benutzerkontos mit vom Angreifer vorgegebenen Zugangsdaten oder das „Heraufstufen“ eines vom Angreifer zuvor angelegten Benutzerkontos sein. Welche Funktionen auch immer dem angegriffenen Benutzer zur Verfügung stehen, können vom Angreifer für seine Zwecke missbraucht werden.

JavaScript kommt sich selbst in die Quere

Kommen wir nun zu JavaScript selbst. Zu dessen Sicherheitsfunktionen hat Ahamed Nafeez auf der „Hack in the Box“ Amsterdam 2014 einen interessanten Vortrag gehalten: „JS Suicide: Using JavaScript Security Features to Kill JS Security“ [5]. Nafeez zeigte, wie verschiedene Features von JavaScript ausgenutzt werden können, um in JavaScript implementierte Schutzfunktionen auszuhebeln.

Als erstes Beispiel dient ihm die Bibliothek OWASP CSRFGuard, die Tokens zum Verhindern von CSRF-Angriffen in die Seiten einfügt. Solch ein Token wird in der CSRFGuard-JavaScript-Datei gespeichert und ist durch eine Funktion geschützt, die Zugriffe durch von anderen Domains geladenen JavaScript-Code verhindert. Oder besser: verhindern soll, denn der Schutz lässt sich aushebeln. Zum Beispiel indem die dabei verwendeten Funktionen vom Angreifer definiert und das entsprechende Objekt eingefr...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang