Anzeige
Auch fremde Webseiten können den Code in dynamisch generierten Skripten auslesen - eine bisher offenbar unterschätzte Gefahr.
Auch fremde Webseiten können den Code in dynamisch generierten Skripten auslesen - eine bisher offenbar unterschätzte Gefahr. (Bild: Usenix-Paper)

Websicherheit: Datenleck durch dynamische Skripte

Auch fremde Webseiten können den Code in dynamisch generierten Skripten auslesen - eine bisher offenbar unterschätzte Gefahr.
Auch fremde Webseiten können den Code in dynamisch generierten Skripten auslesen - eine bisher offenbar unterschätzte Gefahr. (Bild: Usenix-Paper)

Moderne Webseiten erstellen häufig dynamischen Javascript-Code. Wenn darin private Daten enthalten sind, können fremde Webseiten diese auslesen. Bei einer Untersuchung von Sicherheitsforschern war ein Drittel der untersuchten Webseiten von diesem Problem betroffen.

Anzeige

Eine neue Variante sogenannter Cross-Site-Scripting-Inclusion-Sicherheitslücken (XSSI) haben Sicherheitsforscher auf der Black Hat Amsterdam präsentiert. Viele Webseiten erstellen dynamischen Javascript-Code, der sensible Daten enthält. Das ist keine gute Idee: Wird Javascript-Code von einer fremden Webseite eingebunden, wird dieser in dem gleichen Kontext ausgeführt. Dadurch lassen sich die dort enthaltenen Daten in den meisten Fällen auslesen. Sebastian Lekies von der Universität Bochum, Ben Stock von der Universität des Saarlandes und Martin Johns, Sicherheitsforscher bei SAP, fanden zahlreiche populäre Webseiten, die von diesem Problem betroffen sind.

Frühere Lücken durch Browser-Quirks möglich

Schon 2006 wurde eine ähnlich gelagerte Sicherheitslücke in Gmail entdeckt. Auf der Gmail-Domain war bei eingeloggten Nutzern eine JSON-Datei abrufbar, deren Inhalt das Adressbuch des Nutzers enthielt. Dank der Same-Origin-Policy von Javascript kann ein fremdes Skript derartige Daten nicht direkt auslesen. Allerdings war es möglich, diese JSON-Datei als Javascript-Code so einzubinden, dass die Daten als gültiger Javascript-Array interpretiert wurden.

Derartige Lücken waren in der Vergangenheit jedoch nur möglich, weil die Webbrowser manchmal sehr tolerant im Interpretieren von Daten sind. So sehen Browser oft über Syntaxfehler in Dateien hinweg und akzeptieren diese auch, wenn sie mit dem falschen MIME-Type gesendet werden. Die in der Vergangenheit entdeckten Lücken führten dazu, dass die Browser weniger tolerant bei der Interpretation von Javascript-Code wurden.

Javascript-Code verrät Daten

Anders verhält sich die Sache, wenn sich sensible Daten direkt im Javascript-Code befinden. Erzeugt eine Webseite Javascript-Code, der in Variablen sensible Daten enthält - das können private Informationen wie Adressen und Telefonnummern sein, aber auch Tokens zum Schutz vor Cross-Site-Request-Forgery-Angriffen -, dann kann eine andere Webseite diesen Code völlig korrekt einbinden. Die jeweiligen Cookies des Nutzers werden dabei mitübertragen, somit wird der dynamisch erzeugte Code im Kontext einer fremden Webseite ausgeführt. In den meisten Fällen ist es dann für diese Webseite möglich, die dort enthaltenen Daten auszulesen.

Trivial ist das Auslesen, wenn sich die privaten Daten in globalen Variablen befinden. Aber auch wenn die Daten nur in lokalen Variablen in Funktionen enthalten sind, gibt es zahlreiche Wege, an die Daten zu gelangen. Insgesamt fanden die beteiligten Forscher fünf Wege, um entsprechende Daten auszulesen.

Browserplugin hilft bei Analyse

Das Problem ist offenbar weit verbreitet. Ein Browserplugin half bei der Untersuchung von Webseiten. Dieses Plugin prüfte bei allen in einer Webseite eingebundenen Javascript-Dateien, ob diese unterschiedlich sind, wenn man sie jeweils mit und ohne Cookies abruft. Insgesamt prüften die Forscher 150 populäre Webdienste, bei denen man sich mit Accounts anmelden muss. Davon waren insgesamt 49 Webseiten von dem Problem betroffen. Auf 34 Seiten waren eindeutige Identifizierungsmerkmale des Accounts zu finden, die beispielsweise zum Tracking missbraucht werden könnten. Persönliche Daten wie beispielsweise Telefonnummern oder Adressen fanden sich auf 15 Seiten, Tokens, die vor Cross-Site-Request-Forgery-Angriffen (CSRF) schützen sollten, fanden sich auf sieben Seiten.

In den meisten Fällen waren diese Seiten für Angriffe verwundbar, bei einigen wenigen Seiten wurde dies jedoch verhindert, weil die URL des jeweiligen Skripts auch dynamisch erstellt wurde und somit ein potenzieller Angreifer diese URL nicht weiß. Es handelte sich dabei aber vermutlich nicht um eine bewusste Schutzmaßnahme vor diesem Angriff, sondern um reinen Zufall.

E-Mails lesen und auf Facebook-Seite posten

Bei einer News-Webseite fanden die Forscher zusätzlich eine Cross-Site-Scripting-Lücke. Diese ließ sich allerdings nicht direkt ausnutzen, da das entsprechende Formular mittels eines CSRF-Tokens geschützt war und somit nur von dem Nutzer selbst ausgelöst werden konnte. Doch der CSRF-Token befand sich im Javascript-Code. Somit könnte ein Angreifer zunächst die Cross-Site-Scripting-Lücke mit dem ausgelesenen Token ausnutzen. Anschließend war es möglich, die Funktionalität der News-Seite zum Posten auf der Facebook-Seite auszulösen.

Bei einem E-Mail-Anbieter fanden sich die kompletten Inhalte der E-Mails im dynamischen Javascript-Code. Eine bösartige Webseite könnte also die Mails mitlesen. Bei einem Filehosting-Anbieter ließ sich ein Authentifizierungstoken auslesen, mit dem sich sämtliche Aktionen innerhalb des jeweiligen Webinterfaces auslösen ließen.

Namen der betroffenen Seiten nannten die Forscher nicht. Sie hatten nach eigenen Angaben die Betreiber informiert, von ihnen jedoch keine Reaktion erhalten. Die Seiten sind somit nach wie vor verwundbar.

Als Schutzmaßnahme könnten derartige Skripte theoretisch die Referrer-URL prüfen. Das sei jedoch, so die Vortragenden, eher fehleranfällig. Auch wäre es möglich, den dynamischen Javascript-Code nur auszugeben, wenn ein geheimer Token in der URL übergeben wird.

Nicht möglich sind derartige Angriffe auch, wenn der dynamisch erzeugte Javascript-Code nicht aus einer eigenen Datei eingebunden wird, sondern wenn Inline-Javascript genutzt wird. Doch Inline-Javascript verträgt sich schlecht mit einer Technologie namens Content Security Policy. Dieses Verfahren schützt sehr effektiv vor Cross-Site-Scripting-Lücken. Die weitere Verbreitung von Content Security Policy könnte also dazu führen, dass derartige Sicherheitslücken bei der Einbindung von dynamischen Skripten in Zukunft noch zunehmen.

Code und Daten trennen

Die beste Schutzmaßnahme vor derartigen Sicherheitslücken ist, komplett auf dynamisch generierten Code zu verzichten. Private Daten sollten schlicht nicht Teil des Javascript-Codes sein. Eine klare Trennung zwischen Code und Daten würde derartige Angriffe komplett verhindern.

Ein Hintergrundpapier zu den Angriffen wurde auf der Usenix-Konferenz im August veröffentlicht.


eye home zur Startseite
Xiut 16. Nov 2015

Dieser Teil ist echt gefährlich, wenn man nicht genauere Informationen und Umstände...

Geistesgegenwart 15. Nov 2015

Nö. Der Gag ist ja gerade das du durch einbinden eines Elements JavaScript (!= JSON...

Kommentieren



Anzeige

  1. Gruppenleiter Projekte und Systembetreuung (m/w)
    BAS Abrechnungsservice GmbH & Co. KG, Berlin
  2. Java Softwareingenieur/in OES Diagnostics
    Robert Bosch GmbH, Plochingen
  3. IT-Spezialistin/IT-Spezialist (Windows-Arbeitsplätze)
    Landeshauptstadt München, München
  4. Abteilungsleiter/-in SAP-Strategie und übergreifende Aufgaben
    Dataport, Hamburg, Altenholz bei Kiel oder Magdeburg

Detailsuche



Anzeige
Top-Angebote
  1. NUR NOCH HEUTE: Logitech G610 Orion Brown
    92,52€ statt 112,52€ (Vergleichspreise ab ca. 109€)
  2. NUR NOCH HEUTE: Logitech G900 Chaos Spectrum (kabelgebunden/kabellos)
    159,00€ statt 179,00€ (Vergleichspreise ab ca. 179€)
  3. NUR NOCH HEUTE: Gratis Roccat Lua Tri-Button Maus + Kanga Cloth Mousepad Bundle bei Kauf einer ausgewählten Gainward-Grafikkarte

Weitere Angebote


Folgen Sie uns
       


  1. Kniterate

    Der Maker lässt stricken

  2. Maker Faire Hannover 2016

    Denkt denn keiner an die Kinder? Doch, alle!

  3. Bundesverfassungsgericht

    Hip-Hop bleibt erlaubt

  4. Tubeninja

    Youtube fordert Streamripper zur Schließung auf

  5. iPhone 7

    Erste Kopfhörer-Adapter für Lightning-auf-Klinke gesichtet

  6. Wiko Jerry

    Das schwer zu bekommende 100-Euro-Smartphone

  7. Snapdragon Wear 1100

    Neuer Chip für kleine Linux- und RTOS-Wearables

  8. 8x Asus ROG

    180-Hz-Display, Project Avalon, SLI-WaKü-Notebook & mehr

  9. Velohub Blinkers

    Blinker und Laserabstandhalter fürs Fahrrad

  10. Intel Core i7-6950X im Test

    Mehr Kerne für mehr Euros



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
GPD XD im Test: Zwischen Nintendo 3DS und PS Vita ist noch Platz
GPD XD im Test
Zwischen Nintendo 3DS und PS Vita ist noch Platz
  1. Gran Turismo Sport Ein Bündnis mit der Realität
  2. Xbox Scorpio Schneller als Playstation Neo und mit Rift-Unterstützung
  3. AMD Drei Konsolen-Chips für 2017 angekündigt

Xperia X im Hands on: Sonys vorgetäuschte Oberklasse
Xperia X im Hands on
Sonys vorgetäuschte Oberklasse
  1. Die Woche im Video Die Schoko-Burger-Woche bei Golem.de - mmhhhh!
  2. Android 6.0 Ein großer Haufen Marshmallow für Samsung und Co.
  3. Google Android N erscheint auch für Nicht-Nexus-Smartphones

Oracle vs. Google: Wie man Geschworene am besten verwirrt
Oracle vs. Google
Wie man Geschworene am besten verwirrt
  1. Oracle-Anwältin nach Niederlage "Google hat die GPL getötet"
  2. Java-Rechtsstreit Oracle verliert gegen Google
  3. Oracle vs. Google Wie viel Fair Use steckt in 11.000 Codezeilen?

  1. Re: Nur ein Anschluss ist sinnvoll!?

    HiddenX | 11:45

  2. Re: es ist der einzige Weg die GEMA-Sperre zu umgehen

    Poison Nuke | 11:45

  3. Re: wenn selbst der virtuelle Radweg zu schmal ist..

    Stoker | 11:45

  4. Re: Diese Überschrift

    Bouncy | 11:45

  5. Re: Mp3 Ripper...

    Koto | 11:45


  1. 11:49

  2. 11:41

  3. 11:03

  4. 10:40

  5. 10:08

  6. 09:54

  7. 09:10

  8. 08:56


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel