Bypassing the Edge, Chrome, and Safari’s Content Security Policy
Web applications rely on various security mechanisms to protect against malicious attacks. One such mechanism is the same-origin policy, which restricts a web application’s access to resources based on their origin. However, this policy can be bypassed by attackers using techniques like Cross-Site Scripting (XSS). To counter this, Content Security Policy (CSP) was introduced, which allows developers to specify a whitelist of trusted sources for their web application’s code. But, as researchers have discovered, even CSP can be bypassed by attackers.
The Same-Origin Policy
The same-origin policy is a fundamental security mechanism that prevents a web application from accessing resources from a different origin. This policy ensures that a script executed in the context of a web browser can only access resources from the same server. For example, if a script is executed in the context of a web browser with the source server as good.example.com, it can only access resources from good.example.com. However, if a script from evil.example.com tries to access resources from good.example.com, the same-origin policy will prevent it.
XSS Attacks
XSS attacks allow attackers to inject malicious code into a web application, which can then be executed by the browser. This can lead to a range of security vulnerabilities, including information disclosure and session hijacking. To defend against XSS attacks, Content Security Policy (CSP) was introduced.
Content Security Policy
Content Security Policy is a security mechanism that allows developers to specify a whitelist of trusted sources for their web application’s code. This policy is enforced by the browser, which only allows code from trusted sources to be executed. The CSP policy is defined in a HTTP header called Content-Security-Policy, which can be configured to specify the trusted sources.
Bypassing CSP
Researchers have discovered a way to bypass the CSP policy in Microsoft Edge, Google Chrome, and Safari browsers. This vulnerability allows an attacker to inject malicious code into the browser, which can then be executed without being subject to the CSP policy. The exploit involves using the “unsafe-inline” instruction in the CSP policy to load inline code, and then using the window.open() function to create a new page. The attacker can then use the document.write function to write malicious script to the page, which can bypass the CSP policy.
Technical Details
The technical details of this vulnerability are as follows:
- CVE-2017-2419
- CVE-2017-5033
- Talos-2017-0306
The CSP policy defines a “script-src” instruction that is used to configure the script code corresponding to the CSP policy. For example, the following line of code defines the CSP policy:
Content-Security-Policy: script-src 'self' https://good.example.com
This policy allows the browser to only load script resources from the server or good.example.com.
Discussion
This vulnerability may not seem as serious as other security vulnerabilities, such as remote code execution or sandbox escape. However, an attacker can use XSS attacks to steal private data and even end-user account control, which can have severe consequences. Content Security Policy is designed to defend against XSS attacks by allowing the server to add a trusted resource to the whitelist, and the browser can safely perform these resources. However, the specific implementation of CSP differs between browsers, which can allow an attacker to write specific code for a particular browser to bypass the restricted content security policy.
Recommendations
We recommend that users provide a more complete support for the CSP browser, and also keep the browser up to date to protect against all newly discovered security vulnerabilities. This paper was involved in the Tencent cloud from media-sharing plan, and we welcome you to join and share together.