Content Security Policy: Schutz vor Cross-Site-Scripting

Mit der Version 23 soll Firefox offiziell Unterstützung für Content Security Policy erhalten. Die ermöglicht es Webentwicklern, Angriffe durch Cross-Site-Scripting (XSS) deutlich zu erschweren.

Artikel veröffentlicht am 13. Juni 2013, 16:56 Uhr, Hanno Böck

Content Security Policies sollen vor Cross-Site-Scripting schützen. (Bild: virtualforge.de/Screenshot: Golem.de)

Sogenannte XSS- oder Cross-Site-Scripting-Angriffe gehören zu den größten Sicherheitsproblemen bei Webanwendungen. Gelingt es einem Angreifer, Javascript-Code in eine durch einen Login geschützte Webseite einzuschleusen, sind beliebige Angriffe möglich. Ein Angreifer kann die Session seines Opfers übernehmen, Daten löschen und verändern oder auch seinem Opfer fehlerhafte Seiteninhalte vorgaukeln.

Browserhersteller arbeiten seit einigen Jahren unter dem Dach des Standardisierungsgremiums W3C an einem System, welches derartige Angriffe deutlich erschweren soll. Mit Content Security Policy können die Entwickler einer Webanwendung detailliert festlegen, aus welchen Quellen Javascript-Code oder andere Inhalte wie etwa Bilder von einer Webseite genutzt werden können. Mit der übernächsten Version 23 soll das Konzept nun offiziell Einzug in den Firefox-Browser halten. Chrome unterstützt Content Security Policy bereits seit Version 25.

XSS-Angriffe häufiges Problem

Cross-Site-Scripting-Angriffe sind immer dann möglich, wenn eine Webseite externe Eingaben ungefiltert im HTML-Code ausgibt. Ein Beispiel wäre etwa eine Webseite, die dem User ein Suchformular anbietet, welches eine URL der Form http://beispiel.com/suche?suchbegriff=test ansteuert. Ein Angreifer kann nun durch den Aufruf etwa von

http://beispiel.com/suche?suchbegriff=<script>somecode()</script>

versuchen, dort Javascript-Code einzuschleusen.

Üblicherweise sollte daher jede Eingabe, die von einer möglicherweise nicht vertrauenswürdigen Quelle stammt, gefiltert werden. HTML-Sonderzeichen wie <, > und & müssen entweder entfernt oder entsprechend umgewandelt werden. Doch häufig vergessen Webentwickler dies und eine Cross-Site-Scripting-Lücke entsteht.

HTTP-Header verhindert Angriffe

Content Security Policy besteht im Kern aus einem HTTP-Header. Ein einfaches Beispiel wäre der Header Content-Security-Policy: script-src 'self'. In PHP könnte dieser etwa mit dem Befehl header("Content-Security-Policy: script-src 'self'") übertragen werden.

Zahlreiche Browserhersteller haben schon längere Zeit unfertige Implementierungen von Content Security Policy ausgeliefert. Diese wurden dann aber mit anderen Headernamen genutzt. Firefox etwa verwendete bisher x-Content-Security-Policy, Webkit-basierte Browser wie Chrome oder Safari dagegen X-Webkit-CSP. Seit Version 25 unterstützt Chrome den Standard-Header-Namen Content-Security-Policy, in Firefox wird dies mit der offiziellen Einführung in Version 23 passieren.

Das oben genannte Beispiel script-src 'self' bedeutet nun, dass Scripte ausschließlich vom eigenen Server nachgeladen werden können. So kann etwa im Header einer Seite Javascript-Code mit der HTML-Direktive

<script type="text/javascript" src="beispiel.js"></script>

eingefügt werden. Soll nun zusätzlich externer Javascript-Code ermöglicht werden, muss der Header entsprechend angepasst werden. Angenommen, der Javascript-Code für Google Ads soll verwendet werden. Der entsprechende HTML-Code lautet

<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

Damit wird zusätzlich die Domain pagead2.googlesyndication.com zugelassen. Der Inhalt des Content Security Policy-Headers muss dann noch in script-src 'self' pagead2.googlesyndication.com geändert werden. Die Sicherheitsrichtlinien können aber nicht nur für Code definiert werden.