Content Security Policy

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

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-Draft Arbeitsgruppe zur Sicherheit von Webanwendungen[2].

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

Status[Bearbeiten]

Der offizielle Name des Header-Felds ist Content-Security-Policy. Mozilla Firefox unterstützt diesen ab Version 23.[3] Google Chrome seit Version 25.[4]

Die Vorabversion des Internet Explorers verwendet den Namen X-Content-Security-Policy. Ältere Versionen von Google Chrome (2011) und andere WebKit-Browser (Safari) verwenden X-WebKit-CSP. Die Unterstützung des Entwurfs in Firefox und Chrome ist fast vollständig.[2]

Derzeit ist seitens W3C Version 1.1 in Ausarbeitung [5][6]

Problem des klassischen Sicherheitskonzepts[Bearbeiten]

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[Bearbeiten]

Konzept[Bearbeiten]

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 ist der JavaScript-Code statisch und wird nicht dynamisch generiert.

Verbotene Konstrukte und Alternativen[Bearbeiten]

Die Trennung zwischen Code und Daten wird folgendermaßen erreicht:

JavaScript-Blöcke 
der Form <script> [code] </script> müssen in externe Dateien in einer vertrauenswürdigen Domäne ausgelagert werden: <script src="externalfile.js"></script>
setTimeout(), setInterval() 
dürfen nicht mehr in der Variante aufgerufen werden, die den Code in einer Zeichenfolge enthält: setTimeout(" [code] ", 100). Stattdessen muss ein function()-Parameter übergeben werden: setTimeout(function() { [code] }, 100).
eval() 
sollte nach Möglichkeit vermieden werden. Moderne Browser bieten zum Parsen von Daten im JSON-Format die Funktionen JSON.parse(jsonString) an.[7]. Über die Policy-Regel "unsafe-eval" kann der eval()-Aufruf explizit erlaubt werden, wodurch allerdings die Schutzfunktion von CSP eingeschränkt wird.
on-events 
wie beispielsweise <a class="historyback" onclick="history.back()"> müssen durch extern registrierte Event-Handler ersetzt werden. Mit Hilfe von JQuery kann dieses Beispiel so umgeschrieben werden: $(".historyback").click(function() {history.back()}). Das "a"-Element wird hierbei über seine CSS-Klasse "historyback" adressiert und ein Eventhandler für das Click-Ereignis registriert.[8]

Evaluierung, Reporting[Bearbeiten]

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. [9][10]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Sid Stamm: Security/CSP/Spec - MozillaWiki. Background. In: wiki.mozilla.org. 11. März 2009, abgerufen am 29. Juni 2011 (englisch): „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.“
  2. a b Vorlage:Internetquelle/Wartung/Zugriffsdatum nicht im ISO-FormatVorlage:Internetquelle/Wartung/Datum nicht im ISO-FormatStatus des Entwurfs. 29.11.2011, abgerufen am 30.12.2011 (englisch).
  3. Vorlage:Internetquelle/Wartung/Zugriffsdatum nicht im ISO-FormatVorlage:Internetquelle/Wartung/Datum nicht im ISO-Formatimelven@mozilla.com: Content Security Policy 1.0 Lands In Firefox. 11.06.2013, abgerufen am 12.07.2013 (englisch).
  4. Vorlage:Internetquelle/Wartung/Zugriffsdatum nicht im ISO-FormatVorlage:Internetquelle/Wartung/Datum nicht im ISO-FormatGoogle: Chrome 25 Beta: Content Security Policy and Shadow DOM. 14.01.2013, abgerufen am 02.04.2013 (englisch).
  5. Content Security Policy 1.1 W3C Editor's Draft. Abgerufen am 22. Juni 2013
  6. Content Security Policy - Proposals for Version 1.1. Abgerufen am 22. Juni 2013
  7. Alexis Deveria: Native JSON. Abgerufen am 17. März 2012 (englisch).
  8. Click Eventhandler. Abgerufen am 17. März 2012 (englisch).
  9. Die Reporting-Funktion der Content-Security-Policy (CSP). Artikel vom 30. August 2011, abgerufen am 22. Juni 2013
  10. W3C - Content-Security-Policy-Report-Only Header Field