Firefox und Twitter schützen vor eingeschleusten Skripten

Gegen das Einschleusen von JavaScript, das sogenannte Cross Site Scripting (kurz XSS), ist vermeintlich kein Kraut gewachsen. Selbst in den Sites etablierter Zahlungsabwickler wie PayPal oder ClickandBuy und sogar deutscher Banken 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 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). 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.

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. Das können Entwickler bereits mit dem Aurora-Zweig 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. 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 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:

• Bodyguard für Webseiten, Content Security Policy schützt Webseiten vor eingeschleustem Code
  

(rei)