imported>Brodkey65: Änderungen von ~2025-31592-53 (Diskussion) auf die letzte Version von DavidFitness zurückgesetzt

2025-11-06T05:06:17Z

Änderungen von ~2025-31592-53 (Diskussion) auf die letzte Version von DavidFitness zurückgesetzt

Neue Seite

'''Content Security Policy''' ('''CSP''') ist ein [[Sicherheitskonzept]], um [[Cross-Site-Scripting]] und andere Angriffe durch Einschleusen von Daten in Webseiten zu verhindern.<ref name="Stamm 2009" /> Es handelt sich um einen [[World Wide Web Consortium|W3C]]-Empfehlungskandidaten zur Sicherheit von Webanwendungen.<ref name="CSPstatus" />

CSP wurde ursprünglich von der [[Mozilla Foundation]] entworfen und in Firefox 4.0 erstmals experimentell unterstützt.

== Status ==

Der offizielle Name des [[HTTP-Header-Feld]]s ist <code>Content-Security-Policy</code>. [[Mozilla Firefox]] unterstützt diesen ab Version 23.<ref name="MozillaBlog" /> [[Google Chrome]] ab Version 25.<ref name="ChromiumBlog" /> Der [[Internet Explorer]] 10 und 11 unterstützen CSP über den Header <code>X-Content-Security-Policy</code>.

Derzeit ist seitens W3C Version 3 in Ausarbeitung.<ref>[https://w3c.github.io/webappsec-csp/ Content Security Policy Level 3], Redakteurentwurf vom 4. August 2017, abgerufen am 16. August 2017.</ref>

== Problem des klassischen Sicherheitskonzepts ==

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.

== Arbeitsweise ==
=== Konzept ===
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.

=== Verbotene Konstrukte und Alternativen ===
Die Trennung zwischen Code und Daten wird folgendermaßen erreicht:

; JavaScript-Blöcke
: der Form
<syntaxhighlight lang="html">
<script> [code] </script>
</syntaxhighlight>
müssen in externe Dateien in einer vertrauenswürdigen Domäne ausgelagert werden:
<syntaxhighlight lang="html">
<script src="externalfile.js"></script>
</syntaxhighlight>
Alternativ können gesamte Code-Blöcke gehasht und als vertrauenswürdige Quelle angegeben werden.

; setTimeout() und setInterval()
: dürfen nicht mehr in der Variante aufgerufen werden, die den Code in einer Zeichenfolge enthält:
<syntaxhighlight lang="javascript">
window.setTimeout("[code]", 100);
</syntaxhighlight>
Stattdessen muss eine Referenz auf einen [[Rückruffunktion|Callback]] übergeben werden:
<syntaxhighlight lang="javascript">
window.setTimeout(function () { [code] }, 100);
</syntaxhighlight>

; eval()
: sollte nach Möglichkeit vermieden werden. Moderne Browser bieten zum Parsen von Daten im [[JSON]]-Format die Funktionen
<syntaxhighlight inline lang="javascript">
JSON.parse(jsonString)
</syntaxhighlight>

an.<ref name="NativeJSON" /> Über die Policy-Regel “<code>unsafe-eval</code>” kann der Aufruf von <code>eval()</code> explizit erlaubt werden, wodurch allerdings die Schutzfunktion von CSP eingeschränkt wird.

; Event-Handler-Attribute
: wie zum Beispiel <code>onclick</code> in
<syntaxhighlight lang="html">
<a id="historyback" onclick="history.back()">…</a>
</syntaxhighlight>
müssen durch von externem Code hinzugefügte Event-Listener ersetzt werden. Das Beispiel kann so in [[JavaScript]] umgesetzt werden:
<syntaxhighlight lang="javascript">
document.getElementById("historyback").addEventListener("click", function () { history.back(); });
</syntaxhighlight>
Das <code>a</code>-Element wird hierbei über seine ID “<code>historyback</code>” adressiert und ein Event-Listener für das <code>click</code>-Ereignis hinzugefügt.

=== Evaluierung, Reporting ===
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 <code>report-uri</code> angegebene URL zu protokollieren. Hierzu muss der ''report-only''-Modus mittels <code>Content-Security-Policy-Report-Only</code>-Header verwendet werden.<ref>[https://www.phpgangsta.de/die-reporting-funktion-der-content-security-policy-csp Die Reporting-Funktion der Content-Security-Policy (CSP)]. Artikel vom 30. August 2011, abgerufen am 14. August 2017.</ref><ref>[https://www.w3.org/TR/CSP/#cspro-header The Content-Security-Policy-Report-Only HTTP Response Header Field]</ref>

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.<ref>{{Internetquelle |url=https://www.secjuice.com/red-team-flaring-using-report-uri/ |titel=Flaring The Blue Team - When You Confuse Them You Lose Them |datum=2018-11-04 |abruf=2019-12-27 |sprache=en}}</ref>

== Weblinks ==
* [https://www.w3.org/TR/CSP/ Content Security Policy Level 3], W3C-Arbeitsentwurf vom 13. September 2016, abgerufen am 14. August 2017.
* [https://w3c.github.io/webappsec-csp/ Content Security Policy Level 3], Redakteurentwurf vom 4. August 2017, abgerufen am 14. August 2017.
* [https://d-mueller.de/blog/content-security-policy-tutorial/ Content Security Policy Tutorial]. Artikel vom 24. September 2012, abgerufen am 14. August 2017.

== Einzelnachweise ==
<references>
<ref name="Stamm 2009">
{{Internetquelle
|autor=Sid Stamm
|url=https://wiki.mozilla.org/index.php?title=Security/CSP/Spec&oldid=133465
|titel=Security/CSP/Spec - MozillaWiki
|titelerg=Background
|werk=wiki.mozilla.org
|datum=2009-03-11
|sprache=en
|zitat=Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection.
|abruf=2011-06-29}}
</ref>
<ref name="MozillaBlog">
{{Internetquelle
|url=https://blog.mozilla.org/security/2013/06/11/content-security-policy-1-0-lands-in-firefox/
|titel=Content Security Policy 1.0 Lands In Firefox
|datum=2013-06-11
|sprache=en
|abruf=2015-12-01}}
</ref>
<ref name="ChromiumBlog">
{{Internetquelle
|url=https://blog.chromium.org/2013/01/content-security-policy-and-shadow-dom.html
|titel=Chrome 25 Beta: Content Security Policy and Shadow DOM
|hrsg=Google
|datum=2013-01-14
|sprache=en
|abruf=2013-04-02}}
</ref>
<ref name="NativeJSON">
{{Internetquelle
|autor=Alexis Deveria
|url=https://caniuse.com/json
|titel=Native JSON
|sprache=en
|abruf=2017-08-14}}
</ref>
<ref name="CSPstatus">
{{Internetquelle
|url=https://www.w3.org/TR/CSP/#status
|titel=Content Security Policy Level 2
|titelerg=Status of this document
|datum=2015-07-21
|sprache=en
|abruf=2015-12-01}}
</ref>
</references>

[[Kategorie:Sicherheitssoftware]]
[[Kategorie:Web-Entwicklung]]

Content Security Policy - Versionsgeschichte

imported>Brodkey65: Änderungen von ~2025-31592-53 (Diskussion) auf die letzte Version von DavidFitness zurückgesetzt