UNDERSTANDING CONTENT SECURITY POLICIES

CSPs are not a new idea. Initially developed by the Mozilla Foundation, the CSP concept was first applied in Firefox 4 in 2011 and became a W3C candidate recommendation in November 2012 (www .w3.org/TR/2012/CR-CSP-20121115). Written by a Web application developer or server administrator, a CSP specifies how content interacts on the website so that the browser knows what website resources it is permitted to execute and render. The motivation behind having CSPs is to mitigate XSS attacks without the need to substantially modify the application’s source code. A CSP plugs the loophole of a same origin policy (SOP). In a typical Web-application security model, an SOP permits scripts running on pages from the same site; the page is typically specified as protocol, hostname, and port number. For example, in “http://www.example.com:8000,” the protocol is http, the hostname is www.example.com, and the port is 8000. The SOP will consider only this com-bination as a legitimate origin, and pages with the same combination can access each other’s DOMs with no restrictions. The SOP is so named because it trusts any content from the same origin—whatever the server from that source delivers. It is also the loophole the attacker can exploit by injecting malicious code into the legitimate, SOP-trusted page. A CSP closes this loophole through its white list, which guides the browser to execute only the listed resources. Thus, even if the attacker finds a way to inject a script into the trusted origin, it would not match the resources and con-tent in the white list and would there-fore be rejected.

CSP Source Directives

CSP source directives control how a client-side browser should behave when it comes across various types of Attacker Victims Vulnerable site Sends  malicious link. Typical scenario of a nonpersistent XSS attack. Victims authenticate themselves at the site and the attacker lures them into loading a malicious link. The link then executes malicious code with the user’s credentials.

protected website content—from Java-Script to connection locations. Of the source directives we chose to describe, the most common are default, script, and style.Default source. Web application de-velopers or server administrators use the default source, or default-src, di-rective to de¬ ne the white list of re-sources. Sample policies using this di-rective areContent-Security-Policy: default- src ‘self’which permits client browsers to load all resources only from the Web appli-cation’s own origin (protocol, host-name, and port number), and Content-Security-Policy: default- src ‘none’which speci¬ es with the keyword nonethat no resource is allowed to load.Script source. The script-src direc-tive controls the loading of JavaScript on the website. The ¬ rst part of the sam-ple policyContent-Security-Policy: default- src ‘none’; script-src script .example.com javascript.example .comspeci¬ es a default-src of ‘none’. The second part permits the client browser to load script from script.example.com and javascript.example.com. The second part overwrites the default-src policy— that is, no resource (script) is permitted to load except from script.example.com and javascript.example.com.Style source. The style-src directive controls the use of Cascading Style Sheets (CSS) and other styles on a web-page. The policyContent-Security-Policy: default- src ‘none’; style-src ‘unsafe- inline’ maxcdn.bootstrapcdn.comallows the use of inline style and the style sheets from bootstrapcdn.com only. It disallows the loading of any other sources, such as the connect, frame, and media sources.Object source. The object-src direc-tive de¬ nes the white list of sources from which the browser is allowed to download resources while construct-ing the <applet>, <object>, and <embed>tags. The sample policyContent-Security-Policy: default- src ‘none’; object-src plugins .example.com applet.example.com¬ rst de¬ nes a default-src of ‘none’ and then permits two valid locations where the object can be loaded.Image source. The img-src direc-tive speci¬ es the domains from which images can be downloaded. In the sam-ple policyContent-Security-Policy: default- src ‘none’; img-src img.example .com images.example.comimages can be downloaded only from img.example.com and images.example .com; all other image-source domains will be blocked.Media source. The media-src direc-tive speci¬ es what media can be down-loaded. In the sample policyContent-Security-Policy: default- src ‘self’; media-src video .example.com youtube.commedia sources are restricted to video .example.com and youtube.com; all other resources must come from the Web application’s own origin

Report-only mode with the report-uri directive

In report-only mode, the CSP tells the browser not to block a disallowed ele-ment. Although seemingly counter-productive, this mode along with the report-uri directive creates a dry run of a CSP configuration with a specified endpoint. Through the directive, the browser can report a policy violation or the existence of harmful content to the server during that run. The server then stores or processes the report for fur-ther action.

RELATED WORK IN XSS AT TACK PRE VE NTION

Others have proposed mechanisms to prevent XSS attacks.4 Noxes, a client-side tool that acts as a Web proxy, dis-allows requests that do not belong to the website and thus thwarts stored XSS attacks.5Browser-enforced embedded policies (BEEPs) let the Web application devel-oper embed a policy in the website by specifying which scripts are allowed to run.6 With a BEEP, the developer can put genuine source scripts in a white list and disable source scripts in certain website regions.Document Structure Integrity (DSI) is a client-server architecture that restricts the interpretation of un- trusted content.7 DSI uses parser-level isolation to isolate inline untrusted data and separates dynamic content from static content. However, this approach requires both servers and clients to cooperatively upgrade to enable protection.Blueprint is a server-side application that encodes content into a model rep-resentation that the client-side part can process. However, applying Blueprint to WordPress increased processing time on average 55 percent; applying it to MediaWiki increased processing time an average 35.6 percent. With little or no modification to application source code, website visi-tors are assured of protection from the unauthorized downloading of the sen-sitive data stored in their browsers. The CSP’s report-only mode along with the report-uri directive gives server administrators the option to test and configure their applications without breaking website functionalities. Although our CSP has many ben-efits, it is not intended as a primary defense mechanism against XSS attacks. Rather, it would best serve as a defense-in-depth mitigation mechanism. A pri-mary defense involves tailored security schemes that validate user inputs and encode user outputs. So far our work has involved CSP 1.0. In future work, we plan to investigate using directives with CSP 2.0, which as of February 2016 was still a W3C working draft.

source : Mitigating Cross-Site Scripting Attacks with a Content Security Policy

0/5 (0 Reviews)

LEAVE A REPLY

Please enter your comment!
Please enter your name here