{"id":647,"date":"2012-09-24T11:00:44","date_gmt":"2012-09-24T09:00:44","guid":{"rendered":"https:\/\/d-mueller.de\/blog\/?p=647"},"modified":"2016-01-11T23:53:30","modified_gmt":"2016-01-11T22:53:30","slug":"content-security-policy-tutorial","status":"publish","type":"post","link":"https:\/\/d-mueller.de\/blog\/content-security-policy-tutorial\/","title":{"rendered":"Content Security Policy – Tutorial"},"content":{"rendered":"
Prefer this in English? An Introduction to Content Security Policy<\/a><\/div>\n

Das Problem Cross-Site-Scripting \/ XSS<\/a> ist pr\u00e4senter denn je – st\u00e4ndig h\u00f6rt man von neuen Angriffen mit teils verheerenden Folgen, die weit \u00fcber das Entstellen von G\u00e4steb\u00fcchern hinausgehen. Seit 2009 in der Entwicklung und mittlerweile mit einer fast vollst\u00e4ndigen Implementierung in Chrome und Firefox schickt sich die Content Security Policy nun an, XSS den Kampf anzusagen. Aktuell befindet sich die CSP noch im Status W3C Working Draft<\/a> und wird speziell um HTML5-relevante Features wie etwa Web-Sockets erg\u00e4nzt. Das hei\u00dft umgekehrt, dass man sie bereits heute problemlos verwenden kann. Aber von vorne.<\/p>\n

Was ist die Content Security Policy<\/h2>\n

Haupt-Pattern bei XSS-Angriffen ist das Einschleusen von Inline-Script in den HTML-Code, der dann bei jedem Request mit ausgeliefert und ausgef\u00fchrt wird. Javascript sollte in einer idealen Welt ohnehin ausschlie\u00dflich in externen .js-Dateien ausgeliefert werden. So verfolgt die CSP das Konzept, Javascript nur dann auszuf\u00fchren, wenn es sich in einem Script-File befindet. Selbstverst\u00e4ndlich ist der Browser des Nutzers selbst f\u00fcr die Einhaltung der CSP zust\u00e4ndig, sodass der Schutz auf Clientseite erfolgt – Inline-Scripts werden also trotz verseuchtem HTML nicht ausgef\u00fchrt, wenn der Browser des Nutzers CSP unterst\u00fctzt. Hierzu m\u00fcssen evtl. einige Anpassungen durchgef\u00fchrt werden:<\/p>\n

\r\n<a id="mylink" onclick="foo()">Foo<\/a>\r\n<\/pre>\n
… wird dann zu …<\/p>\n
\r\n<script src="script.js"><\/script>\r\n<a id="mylink">Foo<\/a>\r\n<\/pre>\n
… mit der Hilfe von jQuery in der Datei script.js<\/i>:<\/p>\n
\r\n$(document).ready(function()\r\n{\r\n    $("#mylink").on("click", function()\r\n    {\r\n        foo();\r\n    });\r\n});\r\n<\/pre>\n
Ohnehin eine gute Praxis, HTML und JS zu trennen.<\/p>\n
Aber CSP kann noch mehr!<\/h2>\n
Die CSP beschr\u00e4nkt sich nicht auf die Bek\u00e4mpfung von Inline-Scripten. Es k\u00f6nnen noch verschiedenste andere Ressourcen reglementiert werden, so etwa von welchen Locations Bilder und CSS-Dateien<\/b> geladen werden d\u00fcrfen. Denn auch von einem Angreifer eingeschleuste, externe CSS-Dateien und Bilder k\u00f6nnen eine Sicherheitsbedrohung darstellen. Die CSP ist so aufgebaut, dass sich f\u00fcr jede Regel Ausnahmen definieren lassen, aber dazu dann sp\u00e4ter mehr in den Beispielen.<\/p>\n
F\u00fcr einige Regeln wie z.B. die Behandlung von Javascript ist noch zus\u00e4tzlich festgelegt, dass etwa eval<\/b> nicht mehr ausgef\u00fchrt wird. Dies kann aber auch wieder erlaubt werden. Weiterhin unterst\u00fctzt die CSP ein Reporting-Verfahren<\/b>: Bei jedem festgestellten Versto\u00df gegen die Policy wird ein vorher anzugebendes Script per POST-Request vom Browser des Nutzers aufgerufen und teilt dem Webmaster so mit, dass es potentielle XSS-Probleme auf der entsprechenden Webseite gibt. Auch toll: Es l\u00e4sst sich ein Testmodus aktivieren, bei dem die CSP nicht aktiv durchgesetzt wird, wohl aber das Reporting angeschaltet ist – so l\u00e4sst sich f\u00fcr den Webmaster schonmal grob absch\u00e4tzen, was die Einf\u00fchrung der CSP auf seinen Seiten f\u00fcr Auswirkungen h\u00e4tte.<\/p>\n
Einbindung der CSP<\/h2>\n
Die CSP wird als HTTP-Header \u00fcbermittelt. In einer fr\u00fcheren Version der Spezifikation wurde auch noch die Einbindung per Meta-Tag unterst\u00fctzt, dies wurde aber mittlerweile wieder gestrichen. Der Header sieht im aktuellen, noch experimentierellen Status der Policy wie folgt aus:<\/p>\n
Chrome<\/h3>\n
\r\nX-WebKit-CSP: <CSP-Regeln hier>\r\n<\/pre>\n
Internet-Explorer + Firefox<\/h3>\n
\r\nX-Content-Security-Policy: <CSP-Regeln hier>\r\n<\/pre>\n
Der finale Header nach Abschluss der Spezifikation<\/h3>\n
\r\nContent-Security-Policy: <CSP-Regeln hier>\r\n<\/pre>\n
Demnach empiehlt sich folgendes Script, um Redundanz zu vermeiden:<\/p>\n
\r\n\/\/sample rule\r\n$csp_rules = "script-src 'self' cdnjs.cloudflare.com; style-src 'self'";\r\n\r\nforeach (array("X-WebKit-CSP", "X-Content-Security-Policy", "Content-Security-Policy") as $csp)\r\n{\r\n\theader($csp . ": " . $csp_rules);\r\n}\r\n<\/pre>\n<\/p>\n
Was umfasst die CSP alles?<\/h2>\n