Content Security Policy (CSP) ist ein Sicherheitskonzept, um Cross-Site-Scripting und andere Angriffe durch Einschleusen von Daten in Webseiten zu verhindern.[1] Es handelt sich um einen W3C-Empfehlungskandidaten zur Sicherheit von Webanwendungen.[2]
CSP wurde ursprünglich von der Mozilla Foundation entworfen und in Firefox 4.0 erstmals experimentell unterstützt.
Der offizielle Name des HTTP-Header-Felds ist Content-Security-Policy
. Mozilla Firefox unterstützt diesen ab Version 23.[3] Google Chrome ab Version 25.[4] Der Internet Explorer 10 und 11 unterstützen CSP über den Header X-Content-Security-Policy
.
Derzeit ist seitens W3C Version 3 in Ausarbeitung.[5]
Webseiten können aktive Inhalte beispielsweise in Form von JavaScript-Code enthalten. Wenn die Webbrowser diesen Code ausführen, erzwingen sie die Einhaltung der Same-Origin-Policy. Dies bedeutet, dass Code von einer Quelle nicht auf Inhalte einer anderen Quelle zugreifen darf. So darf beispielsweise der Code in der Webseite eines Angreifers nicht auf die Elemente einer Onlinebanking-Webseite zugreifen.
In der Praxis sind jedoch Cross-Site-Scripting-Schwachstellen sehr verbreitet, wodurch die Same-Origin-Policy ausgehebelt wird. Eine Cross-Site-Scripting-Schwachstelle entsteht, wenn sich eine Webseite durch fehlerhafte Maskierung Code unterschieben lässt. Aus Sicht des Browsers kommt dieser untergeschobene Code aus der gleichen Quelle wie die angegriffene Webseite.
Die Ursache für Cross-Site-Scripting-Schwachstellen liegt in der fehlerhaften dynamischen Generierung von Inhalten in Webanwendungen. Die Content Security Policy erzwingt daher eine strikte Trennung zwischen Inhaltsdaten im HTML-Code und externen Dateien mit JavaScript-Code. In der Regel sind externe JavaScript-Dateien statisch und werden nicht dynamisch generiert.
Die Trennung zwischen Code und Daten wird folgendermaßen erreicht:
<script> [code] </script>
müssen in externe Dateien in einer vertrauenswürdigen Domäne ausgelagert werden:
<script src="externalfile.js"></script>
Alternativ können gesamte Code-Blöcke gehasht und als vertrauenswürdige Quelle angegeben werden.
window.setTimeout("[code]", 100);
Stattdessen muss eine Referenz auf einen Callback übergeben werden:
window.setTimeout(function () { [code] }, 100);
JSON.parse(jsonString)
an.[6] Über die Policy-Regel “unsafe-eval
” kann der Aufruf von eval()
explizit erlaubt werden, wodurch allerdings die Schutzfunktion von CSP eingeschränkt wird.
onclick
in<a id="historyback" onclick="history.back()">…</a>
müssen durch von externem Code hinzugefügte Event-Listener ersetzt werden. Das Beispiel kann so in JavaScript umgesetzt werden:
document.getElementById("historyback").addEventListener("click", function () { history.back(); });
Das a
-Element wird hierbei über seine ID “historyback
” adressiert und ein Event-Listener für das click
-Ereignis hinzugefügt.
Um die Auswirkungen der Aktivierung der CSP für eine Web-Applikation zu prüfen, ohne aber die CSP selbst durchzusetzen, sieht der W3C-Entwurf eine Möglichkeit vor, Verletzungen der CSP über die über report-uri
angegebene URL zu protokollieren. Hierzu muss der report-only-Modus mittels Content-Security-Policy-Report-Only
-Header verwendet werden.[7][8]
Dieses Reporting ist jedoch problematisch, da Sicherheitsforscher bereits vorgezeigt haben, wie diese Reports absichtlich falsch gesendet werden können und so die Aufmerksamkeit der Administratoren im Rahmen eines Angriffs an eine falsche Stelle gezogen wird. Dieses Verhalten lässt sich nicht einfach beheben, da der Report vom Browser gesendet wird und nicht vom Server.[9]