Everything about CSP (Content Security Policy) and bypassing it like a PRO!!

4 min readAug 17, 2024

What is CSP? 🤔
Content Security Policy (CSP) is a security feature implemented by modern web browsers to prevent various types of attacks, including Cross-Site Scripting (XSS), data injection attacks, and other code injection vulnerabilities.
CSP works by allowing website administrators to specify which sources of content are permitted to be loaded and executed by the web page. This restricts the ability of attackers to inject malicious content, such as scripts or iframes, that could compromise the security of a website.

How Does CSP Work?
Implementation of CSP is conducted through HTTP response headers or in a <meta> tag in the HTML.
These directives specify which types of resources are allowed to load on the page, such as scripts, styles, images, fonts, and other resources.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="Content-Security-Policy" content="
        default-src 'self';
        script-src 'self' https://trusted-cdn.com;
        style-src 'self' https://trusted-cdn.com;
        img-src 'self' data:;
        font-src 'self' https://fonts.googleapis.com;
        object-src 'none';
        frame-ancestors 'none';
        upgrade-insecure-requests;
    ">
    <title>Bypassing CSP like a PRO! </title>
</head>
<body>
    <h1>Hello, World!</h1>
    <script src="https://trusted-cdn.com/script.js"></script>
</body>
</html>

Let’s talk about the technicals……🧐

default-src 'self'; Only allow content to be loaded from the same site. If nothing else is specified, this is the rule that applies to everything.
script-src 'self' https://trusted-cdn.com; Only allow JavaScript to be loaded from the same site or a specific trusted source (like a CDN).
style-src 'self' https://trusted-cdn.com; Only allow CSS stylesheets from the same site or a specific trusted source.
img-src 'self' data:; Only allow images from the same site or from data URLs (which are a way to embed images directly on the page).
font-src 'self' https://fonts.googleapis.com; Only allow fonts from the same site or a specific trusted source like Google Fonts.
object-src 'none';Don’t allow any plugins or Flash content at all.
frame-ancestors 'none';Don’t let this website be embedded inside another website (prevents things like clickjacking).
upgrade-insecure-requests;Automatically turn any HTTP links into secure HTTPS links.

Let’s jump to the exploitation part!!!! 😎

Weak or Misconfigured CSP
* CSP that includes unsafe-inline or unsafe-eval in the script-src.
Try injecting an inline script or using eval() it to execute JavaScript. If the script runs, it indicates a misconfiguration.
CSP with Wildcards
* CSP that includes script-src * or script-src https://*.example.com .Try injecting scripts from various subdomains or external sources to see if they are executed.
Exploiting JSONP
* CSP allows scripts from a source that offers a JSONP endpoint, an attacker might be able to exploit this to execute arbitrary JavaScript.
* The attacker looks for JSONP endpoints on domains allowed by the CSP. For example, if https://example.com is allowed in the script-src, the attacker might find an endpoint like https://example.com/api?callback=Craft a Malicious Request:
The attacker crafts a request that tricks the JSONP endpoint into executing malicious code. Instead of a benign callback function like handleData, the attacker uses something like:

<script src="https://example.com/api?callback=alert(document.cookie)"></script>

The server might respond with:

alert(document.cookie)({"key":"value"});

If the JSONP endpoint is poorly implemented, the alert(document.cookie) function will execute, even though CSP is supposed to prevent inline script execution.

4. Base64-encoded Payloads
* CSP might prevent direct script injection but allows data: URIs.
If data: URIs are allowed by the CSP input:
<img src="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">

To mitigate risks when implementing a Content Security Policy (CSP):

Define a Strict Policy: Start with a restrictive default-src 'none'; and allow specific sources.
Use Nonce/Hash-Based CSP: Allow scripts and styles using nonces or hashes instead of unsafe-inline.
Test in Report-Only Mode: Deploy CSP in report-only mode first to identify issues without breaking functionality.
Monitor CSP Reports: Regularly review CSP violation reports to address potential issues.
Avoid Wildcards: Restrict resource loading to specific origins rather than using wildcards (*).
Use Subresource Integrity (SRI): Ensure external resources are untampered by using SRI.

Happy Hacking!! Stay Safe…

#BugBounty #BypassingCSP #WebSecurity #ContentSecurityPolicy #BugHunting

Everything about CSP (Content Security Policy) and bypassing it like a PRO!!

Written by Shaurya Sharma

No responses yet