Bypass CSP
What is CSP?
Content Security Policy (CSP) is a security mechanism that defines which resources can be fetched or executed by a web page. It acts as a security policy that controls which scripts, images, and iframes can be executed on a specific page and from which sources. CSP is implemented using response headers or meta elements within an HTML page. Once implemented, the browser enforces the policy and actively blocks any violations detected.
How Does CSP Work?
CSP works by restricting the sources from which active and passive content can be loaded. Additionally, it enforces security policies such as preventing the execution of inline JavaScript, disabling the use of eval(), and limiting resource loading to specific origins.
Defining CSP Rules
The following example illustrates a CSP configuration:
Key CSP Directives
Below are some important CSP directives and their functions:
script-src: Defines allowed sources for JavaScript execution, including inline scripts and external script files.
default-src: Sets the default policy for resource loading when specific fetch directives are not defined.
child-src: Controls allowed sources for web workers and embedded frames.
connect-src: Restricts URLs used in interfaces such as
fetch,WebSocket, andXMLHttpRequest.frame-src: Defines allowed sources for
<frame>and<iframe>elements.frame-ancestors: Specifies which sources can embed the current page in
<frame>,<iframe>,<object>, or<embed>elements.img-src: Defines allowed sources for loading images.
manifest-src: Specifies allowed sources for application manifest files.
media-src: Defines sources for loading media files such as audio and video.
object-src: Restricts the sources for
<object>,<embed>, and<applet>elements.base-uri: Specifies allowed base URLs that can be loaded using the
<base>element.form-action: Lists valid endpoints for form submissions using
<form>elements.plugin-types: Restricts the MIME types of plugins that can be invoked.
sandbox: Applies various security restrictions on loaded resources, such as preventing pop-ups, restricting script execution, and enforcing the same-origin policy.
upgrade-insecure-requests: Instructs browsers to upgrade HTTP requests to HTTPS.
CSP Bypass Techniques
1. CSP Misconfiguration
One of the most common reasons for CSP bypass is the use of insecure values in policy definitions. Consider the following CSP header:
The
default-srcdirective acts as a fallback policy for all fetch directives.The wildcard
*allows loading resources from any source.This effectively nullifies the security benefits of CSP.
Another example:
The
script-srcdirective allows JavaScript execution from the specified sources.The presence of
'unsafe-inline'permits inline JavaScript execution, which can lead to Cross-Site Scripting (XSS).The presence of
data:allows loading JavaScript fromdata:URLs, making it easier for attackers to inject malicious scripts.
Example exploit:
2. JSONP-Based CSP Bypass
JSONP (JSON with Padding) is a technique used to bypass the Same-Origin Policy (SOP) by injecting JavaScript payloads into API responses. If a JSONP endpoint is included in the script-src policy, it can be exploited to inject malicious scripts.
Example JSONP endpoint:
If a CSP policy includes accounts.google.com in the script-src directive, an attacker can exploit it as follows:
This allows JavaScript execution from an external source, effectively bypassing CSP.
3. CSP Injection
CSP injection occurs when user-controlled input is reflected in the CSP header. Consider the following vulnerable URL:
If the value of vuln is directly inserted into the CSP header, an attacker can manipulate the policy:
By modifying the script-src directive, an attacker can include a malicious domain, allowing external JavaScript execution.
Author
For further information or discussions, feel free to reach out to:
Last updated