CSP Bypass
Content Security Policy Bypass
Content Security Policy (CSP)
A special HTTP header is used to mitigate certain types of attacks such as cross-site scripting (XSS).
If set up improperly, it introduces misconfigurations and allows attackers to completely bypass the CSP.
CSP header value
made up of directives separated with a semicolon “;”
Some CSP Directives
Script-src
describes where we can load javascript files from.
Default-src
acts as a catchall for everything else.
Media-src
describes where we can load audio and video files from.
frame-ancestors
describes which sites can load this site in an iframe.
Style-src
describes where we can load stylesheets from.
Special Directive Sources
'none'
No URLs match.
'self'
Refers to the origin site with the same scheme and port number.
'unsafe-inline'
Allows the usage of inline scripts or styles.
EX: (onclick, tags, javascript:,)
'unsafe-eval'
Allows the usage of eval in scripts.
sth.ex.com
Only load resources from specified domain
Structure of a CSP header Example
Ways to bypass CSP
1. Basic CSP Bypass
💡Always look out for wildcard permissions.
CSP header:
Content-Security-Policy: script-src 'self' https://cobalt.io https: data *;
XSS payload:
<script src="data:text/javascript,alert(document.domain)"></script>
2. JSONP CSP Bypass
JSONP is a way to bypass the same object policy (SOP).
A JSONP endpoint lets you insert a javascript payload, normally in a GET parameter called “callback” allowing it to bypass the SOP.
CSP header:
script-src https://www.google.com https://accounts.google.com;
XSS payload:
test.com?vuln_param=https://accounts.google.com/o/oauth2/revoke?callback=alert(1)
3. CSP Injection Bypass
If our input is reflected in the CSP header, we can control what value the script-src value is set to by setting it to a domain we control.
CSP header:
script-src payload;
Last updated