HTML5 aus Hackersicht
Kommentare

Der Spion im Browser
Betrachten wir zuerst das Ausspähen von Daten aus dem Local Storage: Teilen sich verschiedene Benutzer einen Host-Namen, können alle auf alle Daten zugreifen, da sie einen gemeinsamen

Der Spion im Browser

Betrachten wir zuerst das Ausspähen von Daten aus dem Local Storage: Teilen sich verschiedene Benutzer einen Host-Namen, können alle auf alle Daten zugreifen, da sie einen gemeinsamen Speicher verwenden. Es gibt keine Möglichkeit, den Zugriff z. B. auf bestimmte Pfadnamen o. Ä. zu beschränken. Das betrifft z. B. Hoster, die ihren Kunden wie früher Geocities einzelne Verzeichnisse zuweisen.

Ein bösartiger Kunde eines solchen Anbieters kann dann auf alle von allen Kunden gespeicherten Daten in den Browsern der Besucher seiner Website zugreifen. Das ist im Allgemeinen wohl nur ein theoretisches Risiko, denn wer würde bei so einem Anbieter schon eine Webanwendung hosten, die sensitive Daten verarbeitet? Aber wie sieht es denn mit den ganzen Social Networks etc. aus?

Auch da teilen sich viele Benutzer den gleichen Hostnamen, und wenn einer davon bösartigen JavaScript-Code in seinem Bereich speichern kann, kann er darüber auf alle vom Social Network im Local Storage abgelegten Daten zugreifen sobald ein Mitglied seinen Bereich aufruft. Weitere Möglichkeiten zum Zugriff auf die Daten fremder Domains sind z. B. XSS- oder CSRF-Angriffe.

Client vs. Server

Ein weiterer Vorteil des clientseitigen Speichers für einen Angreifer: Statt mühsam einen Cookie oder Zugangsdaten auszuspähen und dann darüber z. B. auf das Google-Mail-Konto seines Opfers zuzugreifen, kann er nun direkt auf die zur Offline-Nutzung bereitliegende Kopie der Mailbox zugreifen, nachdem er die Kontrolle über den Browser des Opfers übernommen hat.

Und das muss nicht mal über einen Angriff auf den Webbrowser selbst geschehen: Jeder auf dem Client laufende Schadcode hat Zugriff auf alle darauf gespeicherten Daten, einschließlich der vom Webbrowser gespeicherten (jeweils immer im Rahmen der jeweiligen Benutzerrechte).

War da was?

Manipulationen am Local Storage sind für den Angreifer weitgehend risikolos, da die Webanwendung sie nicht von gewollten Änderungen des Benutzers unterscheiden kann (sofern eine Offlinenutzung möglich ist). Und ob Daten unbefugt gelesen wurden, lässt sich sowieso nicht feststellen.

Beispiel Session-ID

Wenn eine Webanwendung den Local Storage nutzt, wird sie darin meist auch die Session-ID speichern, statt dafür einen zusätzlichen Cookie zu verwenden. Auch für einen Angreifer ist diese Vereinfachung praktisch, denn während für Cookies über das ‚HttpOnly‘ Flag der Zugriff über JavaScript verboten und das Ausspähen erschwert werden kann, ist das beim Local Storage konzeptbedingt nicht möglich.

Darauf soll ja gerade über JavaScript zugegriffen werden. Eingeschleuster JavaScript-Code kann auf einen Cookie mit gesetztem ‚HttpOnly‘ Flag nicht zugreifen, bei Daten im Local Storage ist das aber problemlos möglich (vgl. auch den Cookie-„Dieb“ aus dem XSS-Artikel auf der Heft-CD):

 

Auf den kommenden Seiten erwarten euch…:

  • SQL-Injection-Angriff auf den Client
  • Gefahren für die Clientdatenbank
  • Hartnäckiger XSS-Wurmbefall
  • Lokal gespeicherter Schadcode
  • Cross-Origin Requests
  • Ein kleiner Abstecher: Clickjacking
  • Clickjacking the Like-Button = Likejacking
  • Clickjacking + HTML5 = Neue Angriffsmöglichkeiten
  • Ein praktischer Angriff: Cookiejacking
  • iframe: Sandkasten gegen JavaScript
  • Schöne neue Funktionen, schöne neue Möglichkeiten
  • Info zum Autor Carsten Eilers
  • Links und Literatur
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -