IPC13

JavaScript ist toll, um Dinge kaputt zu machen
Kommentare

JavaScript ist allgegenwärtig. Auf Milliarden von Geräten findet sich im Paket des Webbrowsers eine Engine, auf der der Code bereitwillig ausgeführt wird. Wenn man auch weiß, wie man die Browser dazu bringt, heimlich eingeschleusten Code auszuführen, kann man frei schalten und walten. Johann-Peter Hartmann (Mayflower) zeigt dem Publikum der International PHP Conference 2013 Dinge, bei denen sich die Nackenhaare aufstellen.

In seinem breit angelegten Vortrag zeigt der JavaScript-Veteran Cross Site Scripting, Crossite Request Forgery, wie diese im innerHTML aussehen, wie bescheiden die Browser darauf vorbereitet sind und welche Kniffe man dagegen anwenden kann. Außerdem zeigt er, wie viel Macht Hackern überlassen wird, wenn sie erst einmal Zugriff auf den Browser ihres Angriffsziels erhalten.

Abb. 1: Johann-Peter Hartmann (Mayflower) zeigt, was für einen Schaden man mit JavaScript anrichten kann

Abb. 1: Johann-Peter Hartmann (Mayflower) zeigt, was für einen Schaden man mit JavaScript anrichten kann

 

Ein kritischer Trend vor allem bei Cross Site Scripting Attacken ist, dass immer mehr Dienste auf einer einzigen Webpage stattfinden. So haben eingeschleuste Schadcodes besonders lange Laufzeiten und können über einen größeren Zeitraum Unheil anrichten. Jüngste Escaping Mechanismen arbeiten auch nicht immer zuverlässig und Hacker lassen sich immer wieder neue Tricks einfallen, indem sie etwa s mit ungültigen src-Angaben einbinden und ein onerror: platzieren, das nahezu mit Sicherheit ausgeführt wird. Die wenigsten Browser bemerken den Betrug. Was sich allerdings ändert. Doch darauf kommen wir später zurück.

Dank des neuen Kommunikations-Protokolls WebRTC ist es möglich, ganze IP-Tabellen auszulesen, mit denen der Browser eines Ziels derzeit verbunden ist. So lassen sich IP-Adressen des Intranets herausfinden und Tunnel zu ihnen graben. Und das war noch nicht der Moment, bei dem das betretene Kichern im Publikum am lautesten wurde.

Richtig unheimlich wurde es erst, als Hartmann mit BeEF ein Tool vorgestellt hat, das eine Art Remote Desktop für infizierte Browser darstellt. Mit ihm lassen sich genug Daten aus dem Fremd-Browser abfischen, um eine komplette Web-Identität zu klauen. Alternativ erlaubt es den Zugriff auf Kamera oder Mikrofon; dem dafür auf der Gegenseite nötigen Flash Plug-in wird einfach gesagt, dass man dies dort akzeptiert. Woher das infizierte JavaScript kommen soll? Wie wäre es mit einem Fake-CDN, dessen URL sich nur in einem einzigen Zeichen von Original unterscheidet. Es soll genug Entwickler geben, die sich vertippen und aus Versehen die falsche URL im HTML-Header platzieren.

Ja, aber was kann denn der Entwickler da noch unternehmen, um das zu verhindern? Nun… es gibt in JavaScript jede Menge “Sinks”, also Konstrukte, die die Ausführung beliebigen Codes in sich erlauben, wie etwa eval(), die man einfach nicht verwenden sollte. Und wo immer möglich, sollte man JsHTMLSanitizer, Escaping und Whitelists einsetzen, um dem eingeschleusten Code so viele Riegel wie möglich vorzuschieben.

Bibliotheken wie jQuery oder Paketquellen wie npm sind voller lückenhaftem Code. Im Falle solcher Abhängigkeiten muss man ständig prüfen, wo dort Lücken sein könnten und wann sie über Aktualisierungen geschlossen wurden. Besonders in der Open Source Welt werden Sicherheitslücken schnell im Allgemeinwissen von Hackern aufgesogen.

Auf Browserseite arbeitet man derzeit an den Content Security Policies, doch wurden diese in vielen Fällen trickreich ausgehebelt, sodass sie vermutlich nie für Entwarnung auf dem Gebiet der XSS-Attacken sorgen werden.

Wer mehr Details aus dem Vortrag wissen will, der darf sich gespannt auf das Video freuen, das wir vor Ort aufgezeichnet haben. Im Übrigen empfiehlt sich auch die Lektüre von „Die OWASP-Top-10 der Web-Sicherheitsrisiken„, in der XSS, Injections und weitere Attacken näher beleuchtet werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -