Content Security Policy

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.

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 2015 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]

  • Content-Security-Policy - standard header name proposed by the W3C document. Google Chrome supports this as of version 25.[7] Firefox supports this as of version 23,[8] released on 6 August 2013.[9]WebKit supports this as of version 528 (nightly build).[10]
  • X-WebKit-CSP - deprecated, experimental header introduced into Google Chrome and other WebKit-based browsers (Safari) in 2011.[11]
  • X-Content-Security-Policy - deprecated, experimental header introduced in Gecko 2 based browsers (Firefox 4 to Firefox 22, Thunderbird 3.3, SeaMonkey 2.1).[12]

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 be also delivered within the HTML code using a HTML META tag, although in this case its effectiveness will be limited.[13]

Support for the sandbox directive is also available in Internet Explorer 10 and Internet Explorer 11 using the experimental X-Content-Security-Policy header.[14]

A number of web application frameworks support CSP, for example AngularJS[15] (natively) and Django (middleware).[16] Instructions for Ruby on Rails have been posted by GitHub.[17] 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.

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

  • Subresource Integrity (SRI), to ensure only known, trusted resource files (typically JavaScript, CSS) are loaded from third-party servers (typically CDNs)
  • Mixed Content, to clarify the intended browser's policy on pages loaded over HTTPS and linking content over plaintext HTTP
  • Upgrade Insecure Requests, hinting browsers on how to handle legacy links on pages migrated to HTTPS
  • Credential Management, a unified JavaScript API to access user's credentials to facilitate complex login schemes,
  • Referrer Policy, CSP extension to hint the browser on generation of the Referer headers.[18]

Bypasses

In December 2015[19] and December 2016[20], a few methods of bypassing 'nonce' whitelisting origins was published. In January 2016[21], another method was published, which leverages server-wide CSP whitelisting 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

If the Content-Security-Policy header is present in the server response, a compliant client enforces the declarative whitelist 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:

  • Inline JavaScript code[a]
    • <script> blocks,[b]
    • DOM event handlers as HTML attributes (e.g. onclick)
    • The javascript: links
  • Inline CSS statements
    • <style> block[b]
    • style attributed to HTML elements
  • Dynamic JavaScript code evaluation[c]
    • eval
    • string arguments for setTimeout and setInterval functions
    • new Function constructor
  • Dynamic CSS statements
    • CSSStyleSheet.insertRule method

While using CSP in a new application may be quite straightforward, especially with CSP-compatible JavaScript framework,[d] 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. ^ a b Trusted inline <script> and <style> blocks can individually whitelisted 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] containing details of the violation.

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

Browser add-ons and extensions exemption

According to the original CSP (1.0) Processing Model (2012-2013),[27] 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 to CSP policies.

However, this policy has since been modified (as of CSP 1.1[28]) 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.[29]

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.[30][31]

See also

References

  1. ^ Sid Stamm (2009-03-11). "Security/CSP/Spec - MozillaWiki". wiki.mozilla.org. Retrieved . 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 . 
  3. ^ a b "Can I use Content Security Policy?". Fyrd. Retrieved 2013. 
  4. ^ Robert Hansen (2009-06-01). "Mozilla's Content Security Policy". Archived from the original on March 18, 2015. Retrieved . 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 . 
  6. ^ "Content Security Policy Level 3". W3C. Retrieved . 
  7. ^ "Chrome 25 Beta: Content Security Policy and Shadow DOM". Google. January 14, 2013. Retrieved 2013. 
  8. ^ "Content Security Policy 1.0 lands in Firefox Aurora". Mozilla Foundation. May 29, 2013. Retrieved 2013. 
  9. ^ "RapidRelease/Calendar". Mozilla Foundation. May 29, 2013. Retrieved 2013. 
  10. ^ "Bug 96765 - Implement the "Content-Security-Policy" header". WebKit. October 31, 2012. Retrieved 2015. 
  11. ^ "New Chromium security features, June 2011". Google. June 14, 2011. Retrieved 2013. 
  12. ^ "Introducing Content Security Policy". Mozilla Foundation. Retrieved 2013. 
  13. ^ "HTML META element". Content Security Policy Level 2. W3C. Retrieved . 
  14. ^ "Defense in Depth: Locking Down Mash-Ups with HTML5 Sandbox". Windows Internet Explorer Engineering Team. Retrieved 2014. 
  15. ^ "ngCsp directive". AngularJS. 
  16. ^ "django-security". 
  17. ^ "Content security policy". GitHub. 
  18. ^ a b "Web Application Security Working Group". Retrieved . 
  19. ^ "CSP 2015". XSS Jigsaw. Retrieved 2015. 
  20. ^ Lekies, Sebastian. "Collection of CSP bypasses". Retrieved . 
  21. ^ "An Abusive Relationship with AngularJS". Retrieved 2016. 
  22. ^ OWASP (2017-05-25), AppSec EU 2017 Don't Trust The DOM: Bypassing XSS Mitigations Via Script Gadgets by Sebastian Lekies, retrieved  
  23. ^ West, Mike (June 15, 2012). "An Introduction to Content Security Policy". HTML5 Rocks. Retrieved 2013. 
  24. ^ http://www.w3.org/TR/CSP/#example-violation-report
  25. ^ For example in Django a CSP receiver is available in django-security module.
  26. ^ "Content Security Policy Reporting". report-uri.io. Scott Helme. 
  27. ^ "CSP Processing Model". 2012-11-15. Retrieved . 
  28. ^ "CSP 1.1: Add non-normative language for extensions.". GitHub w3c webappsec. GitHub. 27 Feb 2014. Retrieved 2016. 
  29. ^ "Bug 866522 - Bookmarklets affected by CSP". Bugzilla. Mozilla. 28 Apr 2013. Retrieved 2016. 
  30. ^ "Subverting CSP policies for browser add-ons (extensions).". 2013-09-25. Retrieved . 
  31. ^ "Re: [CSP] Request to amend bookmarklet/extensions sentence in CSP1.1". 2014-08-03. Retrieved . 
  32. ^ "Noscript security suite addon for Firefox". addons.mozilla.org. Retrieved 2017. 
  33. ^ "The NoScript Firefox extension -- Official site". noscript.net. Retrieved 2017. 
  34. ^ "HTTP Switchboard for Chrome". chrome.google.com. Archived from the original on 2014-08-17. 
  35. ^ "HTTP Switchboard for Opera". addons.opera.com. Retrieved 2017. 

External links


  This article uses material from the Wikipedia page available here. It is released under the Creative Commons Attribution-Share-Alike License 3.0.


Content_Security_Policy



 
Connect with defaultLogic
What We've Done
Led Digital Marketing Efforts of Top 500 e-Retailers.
Worked with Top Brands at Leading Agencies.
Successfully Managed Over $50 million in Digital Ad Spend.
Developed Strategies and Processes that Enabled Brands to Grow During an Economic Downturn.
Taught Advanced Internet Marketing Strategies at the graduate level.



Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your IT knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.


  Contact Us