CSP - Content Security Policy

Einführung

CSP sind Metainformationen, die dem Browser vorgeben aus welchen Quellen die aktuelle Seite Skripte, Bilder etc. beziehen darf. Dadurch wird der Benutzer besser gegen CrossSiteScripting geschützt.

Links

https://www.youtube.com/watch?v=1-sx4AmjGCI
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://www.thorsten-willert.de/optimierung/webseitenoptimierung/csp-content-security-policy (deutsch)
https://csp-evaluator.withgoogle.com/
https://processwire.com/modules/markup-content-security-policy/ ProcessWire Module
https://cspvalidator.org/#url=https://dekra-online.de/ (von DEKRA genutzt)

Übersicht als Metatag

<meta http-equiv="Content-Security-Policy" 
        content="default-src 'self' data: gap: 'unsafe-eval' ws: ; 
        style-src 'self' 'unsafe-inline'; 
        script-src https: *.example.com ;
        media-src 'none'; 
        font-src *;
        connect-src *;
        img-src 'self' data: content:;">
        <!--
        Also
        base-uri /abc/; - limit to content in this folder  v2
        form-action ; - limit where forms can be sent  v2
        
        VALUES
        'self' - anything from the same origin
        data: - data-uri (base64 images)
        gap: - phonegap and cordova used by plugins on iOS
        ws: - web sockets
        * - anything except data: and blobs
        filesystem: - access things on the local filesystem
        blob: - allow Binary Large OBjects
        mediastream: - allow streamed media
        content: - used by Cordova
        'none' - prevent anything in the category
        https: - anything over https://
        *.example.com - anything from any subdomain of example.com
        'unsafe-inline' - inline source elements like style attribute, onclick, or script tags 
        'unsafe-eval' - allow javascript eval( ). 
        -->

Reporting & Testing

Man kann zum Testen eine Report only Variante implementieren und zusätzlich eine URI definieren, die verstöße gegen die CSP entgegennimmt.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#sample_violation_report

Beispiele

Common

Examples: Common use cases

This section provides examples of some common security policy scenarios.

Example 1

A web site administrator wants all content to come from the site's own origin (this excludes subdomains.)

Content-Security-Policy: default-src 'self'

Example 2

A web site administrator wants to allow content from a trusted domain and all its subdomains (it doesn't have to be the same domain that the CSP is set on.)

Content-Security-Policy: default-src 'self' trusted.com *.trusted.com

Example 3

A web site administrator wants to allow users of a web application to include images from any origin in their own content, but to restrict audio or video media to trusted providers, and all scripts only to a specific server that hosts trusted code.

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

Here, by default, content is only permitted from the document's origin, with the following exceptions:

   Images may load from anywhere (note the "*" wildcard).
   Media is only allowed from media1.com and media2.com (and not from subdomains of those sites).
   Executable script is only allowed from userscripts.example.com.

Example 4

A web site administrator for an online banking site wants to ensure that all its content is loaded using TLS, in order to prevent attackers from eavesdropping on requests.

Content-Security-Policy: default-src https://onlinebanking.jumbobank.com

The server permits access only to documents being loaded specifically over HTTPS through the single origin onlinebanking.jumbobank.com.

Example 5

A web site administrator of a web mail site wants to allow HTML in email, as well as images loaded from anywhere, but not JavaScript or other potentially dangerous content.

Content-Security-Policy: default-src 'self' *.mailsite.com; img-src *

Note that this example doesn't specify a script-src; with the example CSP, this site uses the setting specified by the default-src directive, which means that scripts can be loaded only from the originating server.

Reporting Beispiel

Sample violation report

Let's consider a page located at http://example.com/signup.html. It uses the following policy, disallowing everything but stylesheets from cdn.example.com.

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

The HTML of signup.html looks like this:

<!DOCTYPE html> <html>

 <head>
   <title>Sign Up</title>
   <link rel="stylesheet" href="css/style.css">
 </head>
 <body>
   ... Content ...
 </body>

</html>

Can you spot the mistake? Stylesheets are allowed to be loaded only from cdn.example.com, yet the website tries to load one from its own origin (http://example.com). A browser capable of enforcing CSP would send the following violation report as a POST request to http://example.com/_/csp-reports, when the document is visited:

{

 "csp-report": {
   "document-uri": "http://example.com/signup.html",
   "referrer": "",
   "blocked-uri": "http://example.com/css/style.css",
   "violated-directive": "style-src cdn.example.com",
   "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
 }

}

As you can see, the report includes the full path to the violating resource in blocked-uri. This is not always the case. For example, if the signup.html attempted to load CSS from http://anothercdn.example.com/stylesheet.css, the browser would not include the full path, but only the origin (http://anothercdn.example.com). The CSP specification gives an explanation of this odd behavior. In summary, this is done to prevent leaking sensitive information about cross-origin resources.