Dipl.-Inform. Carsten Eilers

Scalable Vector Graphic, kurz SVG, ist weit mehr als eine Möglichkeit, Bilder dar zu stellen. Aus Sicherheitssicht ist es eigentlich eher eine Möglichkeit, JavaScript-Schadcode einzuschleusen. Denn das folgende ist zwar eine Scalable Vector Graphic, aber ganz und gar kein 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>

Wenn Sie mir nicht glauben, öffnen Sie einfach das "Bild". Überzeugt? Und dass es wirklich eine korrekte SVG-Datei ist, verrät Ihnen der W3C Markup Validation Service.

Ein Angreifer würde sehr wahrscheinlich dafür sorgen, dass die SVG-Datei auch ein passendes Bild enthält. Falls Sie also im Rahmen von "User generated Content" das Hochladen von SVG-Dateien erlauben, prüfen Sie die sehr sorgfältig auf ihren Inhalt. Nicht alles, was wie ein Bild aussieht, muss auch ein Bild sein. Bzw. es könnte mehr als "nur" ein Bild sein.

Häusliches XSS

Alles bisher zu XSS gesagte, galt für die klassischen XSS-Angriffe: Für reflektives XSS, bei dem der XSS-Code erst zum Beispiel als Eingabe für einen Suchbegriff an den Server geschickt und von diesem dann in der Antwort an den Client quasi reflektiert wird. Für persistentes XSS, bei dem der XSS-Code auf dem Server gespeichert wird und dann später zum Beispiel beim Lesen eines manipulieren Foreneintrags ausgegeben wird. Und für DOM-basiertes XSS, bei dem eine Schwachstelle im Client-Code für das Einschleusen des XSS-Codes ausgenutzt wird, der dadurch vom Server unter Umständen gar nicht gesehen wird.

HTML5 erlaubt eine neue Art von XSS-Angriffen: Resident XSS. So wurde von Artur Janc auf dem 28C3 ein neuer Angriff genannt, bei dem der auf herkömmlichen Weg eingeschleuste XSS-Code zum Beispiel im Local Storage oder der SQL-Datenbank des Webbrowsers gespeichert wird und zusätzlich in einem versteckten iframe oder Tab aktiv bleibt.

Über Resident XSS kann dann ein Rootkit für die Webanwendung realisiert werden: Der Schadcode hat die vollständige Kontrolle über die Kommunikation zwischen Benutzer und angegriffener Webanwendung und kann Aktionen im Rahmen des Benutzers ausführen und Antworten der Webanwendung manipulieren. Und selbst wenn der Webserver oder Benutzer den Angriff erkennt, ist es gar nicht so einfach, den Schadcode wieder los zu werden:

Solange ein Tab oder ein Fenster zur Domain der angegriffenen Webanwendung mit dem Schadcode offen ist, kann der Schadcode die laufende Session manipulieren. Ein über meta-Tag oder Ajax ausgelöster Refresh der Seite kann vom ihm aufgehoben werden, und die Webanwendung kann den Benutzer nicht einmal vor dem laufenden Angriff warnen, da der Schadcode diese Warnung unterdrücken oder manipulieren kann.

Und der Benutzer wird den laufenden Schadcode nicht so leicht los, wie man meinen möchte: Das Schließen des Tabs mit der Webanwendung ist nutzlos, wenn der Schadcode in weiteren Tabs oder versteckten iframes im Kontext der Webanwendung läuft. Auch das Schließen aller Browserfenster und das Beenden des Webbrowsers eliminieren den Schadcode nicht, wenn der sich zum Beispiel im Local Storage oder der SQL-Datenbank eingenistet hat. Löscht der Benutzer den Local Storage, bevor er den Browser neu startet, kann in noch geöffneten Tabs oder Fenstern laufender Schadcode sich sofort wieder im Local Storage einnisten.

Artur Janc hält folgendes Vorgehen für eine mögliche Lösung:

• Schließen aller Browserfenster bis auf eines.
• Schließen aller Tabs in diesem Fenster bis auf einen.
• In diesem verbleibenden Tab about:blank aufrufen.
• Löschen aller von der Webanwendung auf dem Client gespeicherten Daten, also Cookies, Caches, Local Storage, SQL-Datenbank, Local Shared Objects des Flash Players...
• Neustart des Browsers.

Na, wer von Ihnen würde das machen? Wenn eine Webanwendung es verlangt? Vermutlich niemand, oder? Es gibt aber noch eine zweite Möglichkeit, den Resident XSS dem Garaus zu machen: Alternativ kann auch einfach das betroffene Browserprofil gelöscht werden. Aber das macht ja wohl erst recht niemand, oder?

Sie sehen also: Resident XSS wird man ziemlich schwierig wieder los. Da hilft nur eins: Passen Sie auf, dass sie sich sowas gar nicht erst einfangen. Aber das ist recht einfach: Wenn ihre Webanwendung keine XSS-Schwachstellen hat, kann darüber auch kein Resident XSS eingeschleust werden. Und XSS-Schwachstellen sollte es ja generell nicht geben.

In der nächsten Folge geht es um einen neuen Angriff auf Formulare.

Carsten Eilers

Übersicht über alle Artikel zum Thema

HTML5 Security - Eine Einführung

HTML5 Security - SVG und Resident XSS

HTML5 Security - Formulare auf Abwegen

HTML5 Security - Gift für den Application Cache

HTML5 Security - Der Local Storage

HTML5 Security - Die SQL-Datenbank

HTML5 Security - Cross Origin Requests

HTML5 Security - Gefährliche WebSockets

HTML5 Security - postMessage() sicher nutzen