Content Security Policy

Last updated

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. [1] It is a Candidate Recommendation of the W3C working group on Web Application Security, [2] widely supported by modern web browsers. [3] CSP provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website—covered types are JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features.

Contents

Status

The standard, originally named Content Restrictions, was proposed by Robert Hansen in 2004, [4] first implemented in Firefox 4 and quickly picked up by other browsers. Version 1 of the standard was published in 2012 as W3C candidate recommendation [5] and quickly with further versions (Level 2) published in 2014. As of 2023, the draft of Level 3 is being developed with the new features being quickly adopted by the web browsers. [6]

The following header names are in use as part of experimental CSP implementations: [3]

A website can declare multiple CSP headers, also mixing enforcement and report-only ones. Each header will be processed separately by the browser.

CSP can also be delivered within the HTML code using a meta tag, although in this case its effectiveness will be limited. [14]

Internet Explorer 10 and Internet Explorer 11 also support CSP, but only sandbox directive, using the experimental X-Content-Security-Policy header. [15]

A number of web application frameworks support CSP, for example AngularJS [16] (natively) and Django (middleware). [17] Instructions for Ruby on Rails have been posted by GitHub. [18] Web framework support is however only required if the CSP contents somehow depend on the web application's state—such as usage of the nonce origin. Otherwise, the CSP is rather static and can be delivered from web application tiers above the application, for example on load balancer or web server.

Bypasses

In December 2015 [19] and December 2016, [20] a few methods of bypassing 'nonce' allowlisting origins were published. In January 2016, [21] another method was published, which leverages server-wide CSP allowlisting to exploit old and vulnerable versions of JavaScript libraries hosted at the same server (frequent case with CDN servers). In May 2017 [22] one more method was published to bypass CSP using web application frameworks code.

Mode of operation

Mapping between HTML5 and JavaScript features and Content Security Policy controls ContentSecurityPolicy3 diagram.png
Mapping between HTML5 and JavaScript features and Content Security Policy controls

If the Content-Security-Policy header is present in the server response, a compliant client enforces the declarative allowlist policy. One example goal of a policy is a stricter execution mode for JavaScript in order to prevent certain cross-site scripting attacks. In practice this means that a number of features are disabled by default:

While using CSP in a new application may be quite straightforward, especially with CSP-compatible JavaScript framework, [lower-alpha 4] existing applications may require some refactoring—or relaxing the policy. Recommended coding practice for CSP-compatible web applications is to load code from external source files (<script src>), parse JSON instead of evaluating it and use EventTarget.addEventListener() to set event handlers. [23]

Notes

  1. ↑ This behavior can be disabled globally by a special 'unsafe-inline' statement
  2. 1 2 Trusted inline <script> and <style> blocks can be individually allowlisted in the CSP using nonce or hash statements.
  3. ↑ This behavior can be disabled globally by a special 'unsafe-eval' statement
  4. ↑ For example, AngularJS requires only one initialization flag to be switched into the CSP-compatible mode—<html ng-app='' ng-csp=''>

Reporting

Any time a requested resource or script execution violates the policy, the browser will fire a POST request to the value specified in report-uri [24] or report-to [25] containing details of the violation.

CSP reports are standard JSON structures and can be captured either by application's own API [26] or public CSP report receivers.[ citation needed ]

In 2018 security researchers showed how to send false positive reports to the designated receiver specified in report-uri. This allows potential attackers to arbitrarily trigger those alarms and might render them less useful in case of a real attack. [27] This behaviour is intended and cannot be fixed, as the browser (client) is sending the reports.

Browser add-ons and extensions exemption

According to the original CSP (1.0) Processing Model (2012–2013), [28] CSP should not interfere with the operation of browser add-ons or extensions installed by the user. This feature of CSP would have effectively allowed any add-on, extension, or Bookmarklet to inject script into web sites, regardless of the origin of that script, and thus be exempt from CSP policies.

However, this policy has since been modified (as of CSP 1.1 [29] ) with the following wording. Note the use of the word "may" instead of the prior absolute "should (not)" wording:

Note: User agents may allow users to modify or bypass policy enforcement through user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms.

The absolute "should" wording was being used by browser users to request/demand adherence to the policy and have changes installed in popular browsers (Firefox, Chrome, Safari) to support it. This was particularly contentious when sites like Twitter and GitHub started using strong CSP policies, which 'broke' the use of Bookmarklets. [30]

The W3C Web Application Security Working Group considers such script to be part of the Trusted Computing Base implemented by the browser; however, it has been argued to the working group by a representative of Cox Communications that this exemption is a potential security hole that could be exploited by malicious or compromised add-ons or extensions. [31] [32]

Complementary measures

As of 2015 a number of new browser security standards are being proposed by W3C, most of them complementary to CSP: [33]

See also

Related Research Articles

Cross-site scripting (XSS) is a type of security vulnerability that can be found in some web applications. XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. During the second half of 2007, XSSed documented 11,253 site-specific cross-site vulnerabilities, compared to 2,134 "traditional" vulnerabilities documented by Symantec. XSS effects vary in range from petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site's owner network.

Link prefetching allows web browsers to pre-load resources. This speeds up both the loading and rendering of web pages. Prefetching was first introduced in HTML5.

In computer hypertext, a URI fragment is a string of characters that refers to a resource that is subordinate to another, primary resource. The primary resource is identified by a Uniform Resource Identifier (URI), and the fragment identifier points to the subordinate resource.

Meta refresh is a method of instructing a web browser to automatically refresh the current web page or frame after a given time interval, using an HTML meta element with the http-equiv parameter set to "refresh" and a content parameter giving the time interval in seconds. It is also possible to instruct the browser to fetch a different URL when the page is refreshed, by including the alternative URL in the content parameter. By setting the refresh time interval to zero, meta refresh can be used as a method of URL redirection.

In computing, the same-origin policy (SOP) is a concept in the web application security model. Under the policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page through that page's (DOM).

NoScript is a free and open-source extension for Firefox- and Chromium-based web browsers, written and maintained by Giorgio Maone, a software developer and member of the Mozilla Security Group.

A browser extension is a software module for customizing a web browser. Browsers typically allow users to install a variety of extensions, including user interface modifications, cookie management, ad blocking, and the custom scripting and styling of web pages.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

<span class="mw-page-title-main">Firebug (software)</span> Web development add-on for Firefox

Firebug is a discontinued free and open-source web browser extension for Mozilla Firefox that facilitated the live debugging, editing, and monitoring of any website's CSS, HTML, DOM, XHR, and JavaScript.

<span class="mw-page-title-main">Clickjacking</span> Malicious technique of tricking a Web user

Clickjacking is a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.

Web storage, sometimes known as DOM storage, is a standard JavaScript API provided by web browsers. It enables websites to store persistent data on users' devices similar to cookies, but with much larger capacity and no information sent in HTTP headers. There are two main web storage types: local storage and session storage, behaving similarly to persistent cookies and session cookies respectively. Web Storage is standardized by the World Wide Web Consortium (W3C) and WHATWG, and is supported by all major browsers.

Cross-origin resource sharing (CORS) is a mechanism to safely bypass the Same-origin policy, that is, it allows a web page to access restricted resources from a server on a domain different than the domain that served the web page.

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website or web application where unauthorized commands are submitted from a user that the web application trusts. There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript fetch or XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account.

HTML audio is a subject of the HTML specification, incorporating audio input, playback, and synthesis, as well as speech to text, all in the browser.

<span class="mw-page-title-main">PDF.js</span> PDF viewer in JavaScript included in Mozilla Firefox

PDF.js is a JavaScript library that renders Portable Document Format (PDF) files using the web standards-compliant HTML5 Canvas. The project is led by the Mozilla Corporation after Andreas Gal launched it in 2011.

Media Source Extensions (MSE) is a W3C specification that allows JavaScript to send byte streams to media codecs within web browsers that support HTML video and audio. Among other possible uses, this allows the implementation of client-side prefetching and buffering code for streaming media entirely in JavaScript. It is compatible with, but should not be confused with, the Encrypted Media Extensions (EME) specification, and neither requires the use of the other, although many EME implementations are only capable of decrypting media data provided via MSE.

A headless browser is a web browser without a graphical user interface.

uBlock Origin Web browser extension

uBlock Origin is a free and open-source browser extension for content filtering, including ad blocking. The extension is available for Chrome, Chromium, Edge, Firefox, Brave, Opera, Pale Moon, as well as versions of Safari before 13. uBlock Origin has received praise from technology websites and is reported to be much less memory-intensive than other extensions with similar functionality. uBlock Origin's stated purpose is to give users the means to enforce their own (content-filtering) choices.

<span class="mw-page-title-main">WebAssembly</span> Cross-platform assembly language and bytecode designed for execution in web browsers

WebAssembly (Wasm) defines a portable binary-code format and a corresponding text format for executable programs as well as software interfaces for facilitating communication between such programs and their host environment.

References

  1. ↑ Sid Stamm (2009-03-11). "Security/CSP/Spec - MozillaWiki". wiki.mozilla.org. Retrieved 2011-06-29. Content Security Policy is intended to help web designers or server administrators specify how content interacts on their web sites. It helps mitigate and detect types of attacks such as XSS and data injection.
  2. ↑ "State of the draft". 2016-09-13. Retrieved 2016-10-05.
  3. 1 2 "Can I use Content Security Policy?". Fyrd. Retrieved February 22, 2013.
  4. ↑ Robert Hansen (2009-06-01). "Mozilla's Content Security Policy". Archived from the original on March 18, 2015. Retrieved 2011-06-29. Content Restrictions - a way for websites to tell the browser to raise their security on pages where the site knows the content is user submitted and therefore potentially dangerous.
  5. ↑ "Content Security Policy 1.0". W3C. Retrieved 2015-11-13.
  6. ↑ "Content Security Policy Level 3". W3C. Retrieved May 5, 2023.
  7. ↑ "Chrome 25 Beta: Content Security Policy and Shadow DOM". Google. January 14, 2013. Retrieved February 22, 2013.
  8. ↑ "Content Security Policy 1.0 lands in Firefox Aurora". Mozilla Foundation. May 29, 2013. Retrieved June 16, 2013.
  9. ↑ "RapidRelease/Calendar". Mozilla Foundation. May 29, 2013. Retrieved June 16, 2013.
  10. ↑ "Bug 96765 - Implement the "Content-Security-Policy" header". WebKit. October 31, 2012. Retrieved August 7, 2015.
  11. ↑ "Content Security Policy (CSP)". Microsoft. Retrieved February 6, 2020.
  12. ↑ "New Chromium security features, June 2011". Google. June 14, 2011. Retrieved February 22, 2013.
  13. ↑ "Introducing Content Security Policy". Mozilla Foundation. Retrieved February 22, 2013.
  14. ↑ "HTML META element". Content Security Policy Level 2. W3C. Retrieved 2015-11-14.
  15. ↑ "Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox". Windows Internet Explorer Engineering Team. Retrieved April 13, 2014.
  16. ↑ "ngCsp directive". AngularJS. Retrieved October 27, 2020.
  17. ↑ "django-security". GitHub . 21 November 2022.
  18. ↑ "Content security policy". GitHub. 19 April 2013.
  19. ↑ "CSP 2015". XSS Jigsaw. 23 November 2015. Archived from the original on 20 December 2015. Retrieved December 12, 2015.
  20. ↑ Lekies, Sebastian. "Collection of CSP bypasses" . Retrieved 2017-06-05.
  21. ↑ "An Abusive Relationship with AngularJS". 12 December 2015. Retrieved January 5, 2016.
  22. ↑ OWASP (2017-05-25), AppSec EU 2017 Don't Trust The DOM: Bypassing XSS Mitigations Via Script Gadgets by Sebastian Lekies , retrieved 2017-06-05
  23. ↑ West, Mike (June 15, 2012). "An Introduction to Content Security Policy". HTML5 Rocks. Retrieved February 22, 2013.
  24. ↑ "Content Security Policy Level 3". www.w3.org. Retrieved 2021-01-12.
  25. ↑ "CSP: report-to - HTTP | MDN". developer.mozilla.org. Retrieved 2021-01-25.
  26. ↑ For example in Django a CSP receiver is available in django-security module.
  27. ↑ "Flaring The Blue Team - When You Confuse Them You Lose Them". Secjuice. 2018-11-04. Retrieved 2019-12-27.
  28. ↑ "CSP Processing Model". 2012-11-15. Retrieved 2013-10-06.
  29. ↑ "CSP 1.1: Add non-normative language for extensions". GitHub w3c webappsec. GitHub. 27 Feb 2014. Retrieved 14 Sep 2016.
  30. ↑ "Bug 866522 - Bookmarklets affected by CSP". Bugzilla. Mozilla. 28 Apr 2013. Retrieved 14 Sep 2016.
  31. ↑ "Subverting CSP policies for browser add-ons (extensions)". 2013-09-25. Retrieved 2013-10-06.
  32. ↑ "Re: [CSP] Request to amend bookmarklet/extensions sentence in CSP1.1". 2014-08-03. Retrieved 2015-10-08.
  33. 1 2 "Web Application Security Working Group". GitHub . Retrieved 2015-11-13.
  34. ↑ "Noscript security suite addon for Firefox". addons.mozilla.org. Retrieved 11 June 2017.
  35. ↑ "The NoScript Firefox extension — Official site". noscript.net. Retrieved 11 June 2017.
  36. ↑ "HTTP Switchboard for Chrome". chrome.google.com. Archived from the original on 2014-08-17.
  37. ↑ "HTTP Switchboard for Opera". addons.opera.com. Retrieved 11 June 2017.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.