Incorrect Content Security Policy
Play Labs on this vulnerability with SecureFlag!
Description
Content Security Policy (CSP) allows web developers to define a finely tuned set of policies concerning the capability of several web application components. It offers a robust defense-in-depth layer to existing countermeasures in the application, with its primary benefit being the countering of Cross-Site Scripting (XSS) and injection-driven attacks.
It is a perpetually evolving client-side feature, meaning developers cannot rely solely on its presence. Even though it is designed to be backward compatible, some users might still not use a browser that fully supports it. Think of CSP as a last-resort safety net when other security measures fail.
Having said that, following associated best practices by effectively configuring CSP in a web application is important. Recommendations from standard-setting organizations, such as the World Wide Web Consortium (W3C), from which the CSP emerged, are the culmination of pooled best practices and lessons learned.
In most cases, instructing the webserver to return one particular header, Content-Security-Policy, is sufficient when implementing the standard. This header supports an elaborate list of directives and can be used to fine-tune the allowed origin for scripts, other resources, and a few other aspects of the web page behavior.
Impact
The lack of CSP implementation significantly heightens an application’s vulnerability to several attacks. Without solid CSP headers, XSS attacks thrive, allowing attackers to inject malicious scripts into web pages viewed by other users. Clickjacking attacks become easier, where users are tricked into clicking on something different from what they perceive, potentially executing unwanted actions.
In general, the absence of CSP headers can lead to any type of injection against front-end components, where attackers manipulate data inputs to execute harmful code, compromising the application’s integrity and security. Proficient implementation of CSP is paramount to any defense-in-depth approach.
Prevention
Implementing a CSP ruleset into your web applications helps prevent and reduce the likelihood of XSS attacks. The recommendation is to start with a very narrow CSP ruleset and then relax the restrictions according to what the web application requires. For example, if the web page is not loading any remote resources, it is advisable to set default-src 'self'.
By implementing a CSP ruleset, you establish an allowlist, indicating what the client can and can’t accept. It is important to understand the available directives and keywords and to consider harmful input elements like eval() and inline code.
Some of the most commonly used directives include:
-
default-src: Specifies the default policy for loading various types of resources, such as images, scripts, stylesheets, etc. -
script-src: Specifies valid sources for JavaScript. -
object-src: Specifies valid sources for the<object>,<embed>, and<applet>elements. -
style-src: Defines valid sources for stylesheets. -
img-src: Controls which images can be loaded on the webpage. -
font-src: Specifies valid sources for fonts loaded. -
frame-src: Specifies valid sources for nested browsing contexts using elements such as<frame>and<iframe>.
For web pages using inline scripts like <script>...</script> or handlers like onclick="...", it makes sense to move all of this JavaScript code into a separate file because, unless explicitly allowed by 'unsafe-inline', the CSP rule will block this instance.
CSP can be added either via an HTTP header or <meta> tag, which, applied to the example above, looks like:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">
Additionally, notifying the server of instances where untrusted resources have been blocked is a smart way to identify and halt malicious injections. This can be achieved using the appropriate report directive, such as report-to and report-uri.
Testing
Verify that a CSP response header is in place to help mitigate the impact of XSS attacks, such as HTML, DOM, JSON, and JavaScript injection vulnerabilities.
- OWASP ASVS: 14.4.3
References
MDN - Content Security Policy (CSP)