Bypassing Content Security Policies
A write-up for RatSec lab exercises
What are Content Security Policies?
A Content Security Policy (CSP) is a security feature that is implemented by website owners to mitigate the risks associated with cross-site scripting (XSS) attacks. The policy consists of a set of directives that specify the types of content that the browser should allow or disallow on the website. The components of a CSP include:
1. Directive source: This defines the types of content that the policy applies to, such as scripts, stylesheets, images, and multimedia.
2. Allowed sources: This specifies the sources from which the content can be loaded, such as the website’s own domain or specific external domains.
3. Disallowed sources: This specifies the sources from which the content should not be loaded, such as untrusted third-party domains or inline scripts.
4. Reporting endpoints: This specifies the endpoints where the browser should send reports if a violation of the CSP occurs, such as a server or a log file.
By using a CSP, website owners can prevent attackers from injecting malicious code into their website and protect their users from being exploited by XSS attacks.
Where do we find CSPs on a webpage?
Where can find the Content Security Policy (CSP) of a webpage in the HTTP response headers. You can use your web browser’s developer tools to view the headers. In Chrome, for example, you can right-click on the webpage, select “Inspect” from the context menu, and then navigate to the “Network” tab. Refresh the page if necessary, and you should see a list of requests made by the webpage. Click on any request to view its details, including the response headers. The Content Security Policy header will typically start with “Content-Security-Policy:” followed by a set of directives that define the policy.
Content Security Policies can also be found in a <meta> HTML tag. This is known as a “meta tag” Content Security Policy. The meta tag is typically included in the <head> section of the HTML document and specifies the policy using the http-equiv attribute.
It’s worth noting that the <meta> tag approach is less flexible than using the HTTP response header, since it can only set policies for the page it’s included on, whereas the HTTP response header can set policies for all pages on the same origin.
What are common pitfalls that undermine the effectiveness of a CSP?
1. Overly restrictive policies: If the CSP is too restrictive, it can prevent legitimate resources from loading, which can break the functionality of the website. It is important to thoroughly test the policy and ensure that it does not block important resources.
2. Incorrect configuration: Incorrectly configuring a CSP can lead to vulnerabilities being introduced, such as allowing unsafe inline scripts or not including necessary domains in the policy. It is important to review the policy configuration regularly and keep it up to date.
3. Compatibility issues: Some older browsers do not support certain CSP features, so it is important to test the policy on multiple browsers to ensure compatibility. Additionally, some third-party scripts and services may not be compatible with the policy, so it is important to evaluate these services and ensure that they are compatible.
4. Lack of monitoring: Even with a well-configured CSP, there is still the possibility of security incidents occurring. It is important to have a monitoring and incident response plan in place to quickly detect and respond to any security incidents related to the CSP.
5. Lack of awareness: Many website owners and developers are not aware of the importance of CSPs and do not implement them on their sites. This can leave their sites vulnerable to attacks, so it is important to raise awareness about CSPs and encourage their use.
Resources
Security Zines by Rohit and Anshu is an amazing resource that presents infosec topics in an engaging, visual fashion. Check the link below for their zine on CSP and many others.
Portswigger’s XSS Cheat Sheet offers a vast array of payloads. With functionality to filter by tags, events, and browsers, a tester can hone in on the appropriate payload construct. The ability to copy lists in a single click means you can fuzz targets to determine what syntax can penetrate a target.
11.php
In our browser we can use the shortcut Ctrl+Shift+I do view the Developer Tools (this works in both Firefox and Chrome-based Browsers). Select the Network tab, the page file (in this case 11.php), and find the CSP in the Response Headers.
The CSP Evaluator can help too because it provides more robust information on the various attributes of the policy.
This content security policy is telling the browser to only allow scripts to be loaded from specific sources: https://facebook.com, https://google.com, which is a good start but goes on to allow any URL with the prefix “https://” (due to the wildcard ‘*’), and any inline scripts that are explicitly marked as ‘unsafe-inline’. A generic payload such as <script>alert()</script> works here, but let’s think beyond that.
At time of writing, script tags and alert events are often blocked. Additionally, the print can succeed where the alert event fails. We will exploit with a simple payload, that reflects such logic with <img scr=print()>, which will pop up a print dialog window. Another indicator that this payload will be successful is that there is no image source (img-src:) component of the CSP meaning that the page will load images from anywhere. Not ideal, but good for us.
12.php
This CSP is similar to the last lab, except that it contains the ‘unsafe-eval’ directive, whereas the privious included the ‘unsafe-inline’ directive. In general, it’s recommended to avoid using both ‘unsafe-inline’ and ‘unsafe-eval’ in a CSP, and to instead use more specific directives to allow only necessary scripts from trusted sources.
The ‘unsafe-inline’: allows the use of inline scripts (i.e., scripts embedded directly in HTML markup using the ‘script’ element’s “inline” attribute).
The ‘unsafe-eval’: allows the use of ‘eval()’ and similar functions that execute arbitrary code passed as strings.
This time we see that the wildcard (*) domain is preceded with “’unsafe-eval’ data:’” which means that JavaScript will evaluate a function that redirects to an arbitrary domain. We can base64 encode the payload, then have JS evaluate it as data. We will use the payload window.location.replace(“http://www.qwantz.com”), echo it and encrypt on the command line:
Then insert the encoded string into our JS script tag:
<script src= “data:;base64,d2luZG93LmxvY2F0aW9uLnJlcGxhY2UoImh0dHA6Ly93d3cucXdhbnR6LmNvbSIpCg==”></script>
and paste it into the form:
After clicking Submit, we are redirected to the external site from our payload:
13.php
This time we will use the Curl command line tool to inspect the page’s headers with the -I flag, which will fetch only the headers of a given page.
For an explanation, we can always ask Chat-GPT:
It explains that we can only load JS code from the domain https://cdnjs.cloudflare.com.
This CSP is a bit trickier, as it is more restrictive and we don’t have the wildcard domain; we will look to the Hacktricks site for help.
Note that both lines comprise the full payload. Copy into the form:
We have bypassed the CSP and gotten our alert.
14.php
This CSP specifies that scripts on the web page can only be loaded from the data: URI scheme. In this case we will obfuscate our payload as data with the following tag: <script src=data:,alert(document.cookie)></script>
And we get a pop-up with the current session cookies.
In conclusion, a Content Security Policy (CSP) is an important security feature that website owners can implement to mitigate the risks of XSS attacks. A CSP consists of a set of directives that specify the types of content that the browser should allow or disallow on the website. While CSPs can provide effective protection against attacks, there are common pitfalls that can reduce their effectiveness. It’s important to ensure that the policy is not too restrictive, is configured correctly, is compatible with multiple browsers, is monitored regularly, and that website owners and developers are aware of its importance.
