Skip to content

HTML5 Security - SVG und Resident XSS

Weiter geht es mit der kleinen Einführung in die Sicherheit von und mit HTML5. An dieser Stelle sei noch einmal der Hinweis erlaubt, dass das alles sehr viel ausführlicher in meinem auf deutsch und englisch erhältlichen eBook "HTML5 Security" beschrieben ist.

Die neuen Möglichkeiten, HTML5 für XSS-Angriffe zu nutzen, habe ich ja bereits angesprochen. Einen möglichen Angriffsvektor möchte ich noch erwähnen, da der leicht übersehen wird:

Nicht jede Scalable Vector Graphic ist wirklich ein Bild

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

Trackbacks

ffp.gifwelt.info am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 2.2014 - Angriffsziel Webbrowser

Vorschau anzeigen
Im PHP Magazin 2.2014 ist ein Artikel über den aktuellen Stand der Sicherheit von HTML5 und JavaScript erschienen. Im PHP Magazin 3 und 4/2012 wurden zuletzt Artikel über die Sicherheit von HTML5 veröffentlicht. Da drängt s

Dipl.-Inform. Carsten Eilers am : Drucksache: windows.developer Magazin 12.2014 - JavaScript und die Sicherheit

Vorschau anzeigen
Im windows.developer 12.2014 ist ein Artikel über Angriffe zur Sicherheit von JavaScript erschienen. Darin geht es um zwei Themen: Zum einen um einige neue bzw. verbesserte Angriffe, die auf den Sicherheitskonferenzen vorgestellt wurden. Zu

Dipl.-Inform. Carsten Eilers am : Neues eBook: "JavaScript Security - Sicherheit im Webbrowser"

Vorschau anzeigen
Bei entwickler.press ist mein eBook über die Sicherheit von JavaScript erschienen: &quot;JavaScript Security - Sicherheit im Webbrowser&quot; Wie der Name schon sagt geht es um die Sicherheit von JavaScript (und HTML5, dass ja viele neue JavaSc

Dipl.-Inform. Carsten Eilers am : Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Vorschau anzeigen
Nachdem es in der vorherigen Folge um die Universal XSS Schwachstelle im IE ging möchte ich ab dieser Folge ein paar mögliche Angriffe über Cross-Site Scripting vorstellen. Bevor es zu den eigentlichen Angriffen kommt sollen aber er

entwickler.de am : PingBack

Die Anzeige des Inhaltes dieses Trackbacks ist leider nicht möglich.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!