zurück zum Artikel

Firefox und Twitter schützen vor eingeschleusten Skripten

Ronald Eikenberg

"Du kommst hier nicht rein" heißt es für Schadcode, wenn man als Webseiten-Betreiber den HTTP-Header "Content Security Policy" benutzt. Google, Mozilla und Twitter gehen mit gutem Beispiel voran.

Gegen das Einschleusen von JavaScript, das sogenannte Cross Site Scripting (kurz XSS) [1], ist vermeintlich kein Kraut gewachsen. Selbst in den Sites etablierter Zahlungsabwickler wie PayPal [2] oder ClickandBuy [3] und sogar deutscher Banken [4] entdecken Sicherheitsexperten und Schüler immer wieder Schwachstellen, durch die Angreifer eigenen Code einschleusen können. Die möglichen Folgen: Cookie-Klau, Phishing und Malware – alles im Namen der verwundbaren Site.

Freilich könnten (und sollten) sich die Betreiber schützen, indem sie Benutzereingaben penibel auf eingeschleuste Skripte untersuchen. Das geschieht auch, nichtsdestotrotz finden Weiß- und Schwarzhüte immer wieder Schlupflöcher. Das liegt einerseits daran, dass die Hacker auf ein beachtliches Waffenarsenal [5] zurückgreifen können, andererseits spielt ihnen auch die Komplexität moderner Web-Applikationen in die Hände.

Abhilfe verspricht die von Mozilla ins Leben gerufene Spezifikation Content Security Policy (CSP) [6]. Die Funktionsweise einer CSP ist schnell erklärt: Der Betreiber lagert sämtlichen JavaScript-Code strikt in .js-Dateien aus und definiert anschließend über den HTTP-Header in einer Whitelist, aus welchen Quellen seine Seite Skripte nachladen darf. Der Browser wertet den Header aus und blockiert Skripte, die nicht in der Whitelist stehen. Inline-Skripte, also JavaScript direkt im HTML-Code der Seite, ist standardmäßig verboten. Und das ist auch gut so, schließlich sind die der Hauptgrund dafür, dass XSS überhaupt möglich ist.

Und täglich grüßt die XSS-Lücke: Dieser Screenshot wurde auf PayPal.com aufgenommen und steht stellvertretend für viele andere.

Damit eine Content Security Policy durchgesetzt werden kann, müssen zwei Parteien mitspielen: Der Browser, der den CSP-Header auswertet, und der Betreiber der Webseite, der sein Angebote CSP-konform umbaut. Erfreulicherweise kann man auf beiden Seiten Bewegung beobachten: Chrome unterstützt CSP bereits seit einiger Zeit, Firefox und Safari untersützen zumindest Entwurfsversionen der Spezifikation. Mozilla hat gerade erklärt, dass Firefox ab Version 23 auch CSP 1.0 unterstützen soll [7]. Das können Entwickler bereits mit dem Aurora-Zweig [8] bereits jetzt ausprobieren.

Aber auch seitens der Website-Betreiber tut sich etwas: So hat sich etwa Twitter in seinem Engineering-Blog kürzlich erneut zur CSP bekannt [9]. Einige Twitter-Projekte wie die mobile Website oder Tweetdeck liefern bereits eine CSP mit dem Header aus. Das Unternehmen hat sogar eine Ruby-Bibliothek namens secureheaders [10] entwickelt, mit der Entwickler sicherheitsrelevante Header wie CSP selbst mit geringem Aufwand einsetzen können.

Auch wenn derzeit noch nicht alle Browser den CSP-Header unterstützen, ist es eine gute Idee, als Webseitenbetreiber bereits jetzt damit zu beginnen, die neue Schutzfunktion einzubauen: Browser, die den Header nicht kennen, können die CSP-geschützte Webseite nämlich trotzdem problemlos anzeigen; wenn auch ohne das Plus an Schutz.

Die Vor- und Nachteile von Content Security Policy schildert heise Security in einem ausführlichen Artikel:

(rei [12])


URL dieses Artikels:
https://www.heise.de/-1887585

Links in diesem Artikel:
[1] http://www.heise.de/thema/XSS
[2] https://www.heise.de/news/PayPal-wieder-durch-Cross-Site-Scripting-angreifbar-1869515.html
[3] https://www.heise.de/news/Erneut-Sicherheitsluecke-bei-ClickandBuy-1874953.html
[4] https://www.heise.de/news/16-jaehriger-demonstriert-Sicherheitsluecken-bei-17-Banken-1104841.html
[5] https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
[6] http://www.w3.org/TR/CSP/
[7] https://blog.mozilla.org/security/2013/06/11/content-security-policy-1-0-lands-in-firefox/
[8] http://www.mozilla.org/de/firefox/channel/
[9] https://blog.twitter.com/2013/csp-rescue-leveraging-browser-security
[10] https://github.com/twitter/secureheaders
[11] https://www.heise.de/hintergrund/XSS-Bremse-Content-Security-Policy-1888522.html
[12] mailto:rei@heise.de