Skip to content

Drucksache: windows.developer Magazin 4.2015 - Der Browser im Visier - ganz praktisch

Geschrieben von Carsten Eilers am um 10:43

Im windows.developer 4.15 ist ein Artikel über Angriffe auf den Webbrowser erschienen.

Die Schwachstellen in und Angriffe auf oder über den Webbrowser wurden im Windows Developer schon öfter behandelt, zum Beispiel in Ausgabe 3.2014 und 12.2014. Zu kurz gekommen sind dabei die existierenden Proof of Concepts und Exploits, mit denen sich die Schwachstellen und Angriffe nachvollziehen lassen. Es war also höchste Zeit, dass zu ändern.

Es gibt wahrscheinlich unendlich viele Möglichkeiten, mit HTML5 und JavaScript nützliche Webanwendungen zu implementieren. Und eben so viele Möglichkeiten, damit Schaden an zu richten. Ich möchte dazu aus zwei Folien aus einem Vortrag (Präsentation als PDF) zitieren, den ich 2008 auf der Ajax in Action gehalten habe:

Das erste Zitat befasst sich mit den Folgen von XSS-Schwachstellen und -Angriffen:

"• Wer JavaScript ausführen kann, kontrolliert den Browser
• Wer den Browser kontrolliert, ist hinter der Firewall
• Wer den Browser kontrolliert, ist nur einen Schritt von der Kontrolle über das System entfernt"

Das zweite Zitat geht einen Schritt weiter:

"Warum sollte jemand das System übernehmen, wenn der Browser für seine Zwecke reicht?
Port 80 ist fast überall offen, mit WebSockets wird das Loch in der Firewall noch größer"

Das war 2008. Inzwischen haben wir 2015, die Clients der Webanwendungen sind viel umfangreicher geworden als man damals ahnen konnte, und sind damit selbst zu interessanten Zielen für Angreifer geworden. Und damit steigt auch die Gefahr eines Angriffs auf/über JavaScript.

Ich höre oft "Aber das meiste betrifft uns ja nur, wenn wir eine XSS-Schwachstelle haben. Und die haben wir natürlich nicht". Dazu kann ich nur sagen: "Sind Sie sich da ganz sicher?"

Wirklich sicher kann man sich nie sein. Man kann die Webanwendung nur so sorgfältig wie möglich implementieren und alle verfügbaren Schutzmaßnahmen nutzen. Aber selbst wenn danach ein Schwachstellentest keine Schwachstellen zu Tage fördert oder alle gefundenen Schwachstellen behoben wurden, ist das nur eine Momentaufnahme. Zum einen können schon durch kleine Änderungen am Code oder der Konfiguration neue Schwachstellen entstehen, zum anderen werden immer wieder neue Angriffe entwickelt. Und vor denen schützen die bisherigen Schutzmaßnahmen dann nicht unbedingt.

Ein gutes Beispiel für einen zusätzlichen Schutz ist die Content Security Policy. Die reduziert die möglichen Folgen eines XSS-Angriffs. Was ja eigentlich gar nicht nötig ist, so lange die Anwendung keine entsprechende Schwachstelle enthält. Trotzdem sollten Sie sie nutzen. Denn es muss gar keine XSS-Schwachstelle geben, um zum Opfer eingeschleusten JavaScript-Codes wie des BeEF-Client-Codes zu werden. Der kann auch zum Beispiel in einem offenen WLAN von einem Man-in-the-Middle "on the fly" in die Webseiten eingefügt werden.

Und dann gibt es natürlich immer die Gefahr, dass ein Browser eine Universal XSS Schwachstelle enthält, wie es vor kurzem im IE der Fall war. Die erlaubt dann XSS-Angriffe auf alle Websites, auch wenn die selbst keine XSS-Schwachstelle enthalten.

Also: Nutzen Sie alle Möglichkeiten, um Ihre Webanwendung abzusichern. Denn die Cyberkriminellen werden früher oder später jede Möglichkeit für einen Angriff nutzen. Noch sind die weitgehend mit der Verbreitung von Onlinebanking-Trojanern, Spyware und Hintertüren über Drive-by-Infektionen beschäftigt. Aber wenn das eines Tages keinen Erfolg mehr verspricht, werden sie nach neuen Einnahmequellen suchen. Und dann könnten ein Browser-basiertes Botnet oder Angriffe auf Webclients durchaus lukrative Einnahmequellen werden. Und Webanwendungen damit zu einem beliebten Ziel.

Und hier noch die Links und Literaturverweise aus dem Artikel:

Carsten Eilers

Trackbacks

Keine Trackbacks