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.
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