Week 24 - CSP Bypasses
Content Security Policy - Bypasses
For week 24, I wanted to share an in-depth post on Content Security Policies and how to bypass them.
What is a Content Security Policy?
CSP’s tell a browser what paths/sources are safe to load resources from. They are used to prevent Cross-Site Scripting, clickjacking, and similar vulnerabilities involving images, frames or JavaScript. The CSP is specified within a server response header or meta tag, and the browser blocks any payload that violates the policy.
To bypass a CSP, first look for the ‘script-src’ section and determine if any of the following are specified:
‘unsafe-inline’ -> Allows normal XSS payloads:alert(1)
‘unsafe-eval’ -> Allows Base64 encoded payloads:
https: -> Allows external scripts:
data: -> Allows Base64 encoded payloads:
‘self’ AND .js File Upload -> If you can upload a JavaScript file, you can execute it as a script:
Other more exotic bypasses:
Static ‘nonce’ -> If the server's nonce does not change with every request, specify the nonce in the payload to execute:
Lack of object-src and default-src -> Object payloads will render:
Missing base-uri -> Payload loads all relative src paths from your specified attacker server
I find the last base-uri bypass super interesting. It’s useful not just for working around a CSP, but also any application firewall. Frequently we see Cross-Site Scripting payloads involving or HTML events blocked immediately, but it’s much rarer to find a WAF that blocks ">. Just make sure you find a relative script source path used by the application, and upload your JavaScript file to that same path on your server. Then BAM, easy Cross-Site Scripting!!!
Last updated
