1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Websicherheit: Datenleck durch…

Man kann natürlich...

  1. Thema

Neues Thema Ansicht wechseln


  1. Man kann natürlich...

    Autor: LX 14.11.15 - 16:59

    ...seinen JS-Code komplett in einer Closure verstecken und darin noch sicherheitshalber prüfen, ob die verwendeten DOM-Methoden und Literale tatsächlich im Funktions-Body nur "{ [native code] }" beinhalten (Achtung, ({}).toString.call(obj) verwenden, da eine lokale toString-Methode ein korrektes Ergebnis vorgaukeln könnte) und ansonsten jegliche Funktionalität verweigern.

  2. Re: Man kann natürlich...

    Autor: Geistesgegenwart 15.11.15 - 11:13

    LX schrieb:
    --------------------------------------------------------------------------------
    > ...seinen JS-Code komplett in einer Closure verstecken und darin noch
    > sicherheitshalber prüfen, ob die verwendeten DOM-Methoden und Literale
    > tatsächlich im Funktions-Body nur "{ }" beinhalten (Achtung,
    > ({}).toString.call(obj) verwenden, da eine lokale toString-Methode ein
    > korrektes Ergebnis vorgaukeln könnte) und ansonsten jegliche Funktionalität
    > verweigern.

    Nein, so einfach ist das nicht. Und jetzt nicht den Fehler machen man denkt man sei so schlau mit solchen Überprüfungen und schafft mehr sicherheit.

    Die Attacke von 2006 auf GMail bassierte darauf, das man in JavaScript den Array() constructor überschreiben kann - d.h. das im JSON (das als JavaScript interpretiert wurde) vorhandene "[ ... ]" hat den überschriebenen Array() konstruktor aufgerufen, somit konnten die Daten ausgelesen werden. Du kannst übrigens sogar XMLHttpRequeset komplett austauschen durch deine eigene implementierung, und in vielen Fällen auch die toString() Methode überschreiben.

    Die im Artikel benannte Lücke verhindert man, in dem man kein dynamisches (=serverseitiges) JavaScript generiert. Ich finde (als hauptberuflicher Frontend/JS Entwickler) die Idee überhaupt schwachsinnig, CODE (= .js Datei) benutzerspezifisch zu generieren. Wir würden doch auch keine Python oder Perlskripte generieren, die DATEN enthalten. Sondern den Code von vornherein so schreiben, das die Daten nachgeladen oder über entsprechende Datenformate (JSON, YAML) eingelesen würden. Überhaupt will man ja Caching und CDNS verwenden, daher sollte gelten das alle .js Dateien für jeden User immer die gleichen sind.

    JSONP mag eine Ausnahme sein, aber bei den meisten bekannten Libs (z.B. auch jquery) ist jeder JSONP Request mit einem Zufallstoken versehen (nicht nur wegen der Sicherheit sondern auch um das richtige Callback zu erwischen). Da waren wieder frickler am Werk...

  3. Re: Man kann natürlich...

    Autor: LX 15.11.15 - 19:25

    Ist mir alles bekannt. Allerdings setzt ein solcher Angriff voraus, dass ein XSS-Angriff möglich ist.

  4. Re: Man kann natürlich...

    Autor: Geistesgegenwart 15.11.15 - 19:33

    LX schrieb:
    --------------------------------------------------------------------------------
    > Ist mir alles bekannt. Allerdings setzt ein solcher Angriff voraus, dass
    > ein XSS-Angriff möglich ist.

    Nö. Der Gag ist ja gerade das du durch einbinden eines <script> Elements JavaScript (!= JSON) von jeder Domain einbinden kannst, da hier die Same-Origin Policy nicht greif. D.h. du musst das Opfer nur auf eine von dir kontrollierte Seite locken, solange die Session der angegriffenen Seite noch gültig ist. Die Attacke basiert ja darauf, das eine angepasste .js Datei ausgeliefert wird abhängig vom Cookie - zwar kommst du in deiner Angreifer seite nicht an den Cookie ran, brauchst du aber auch nicht der wird vom Browser automatisch gesendet. Du führst dann das .js in einem Kontext aus und kannst alles dortdrinnen enthaltene Auslesen.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Bonn
  2. Bechtle AG, Bonn
  3. Berliner Verkehrsbetriebe (BVG), Berlin
  4. Allianz Deutschland AG, München Unterföhring

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 5,75€
  2. 34,99€ (Release 5. Februar)
  3. 29,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de