NovoGeek's Blog (Archive)

As a follow up of my posts “The uncontrollable web platform” and “The promises of CSP to secure the web”, in this post, I would like to highlight some of the things which are beyond the scope of Content Security Policy. If you have noticed, I did not title the post as “Drawbacks of Content Security Policy (CSP)”, since any stricter version of the current CSP spec will break the existing web or induce performance issues.

During its creation, the World Wide Web was never imagined to have new constructs like social plugins, third party content, web APIs etc. Today, it is already a gigantic tree with billions of webpages online and now we are trying to control its security aspects, so it is quite possible that there would be loopholes or intentionally left areas in modern security policies, which could be misused.

In traditional web architecture, the dominant security problems are XSS, CSRF and Data Exfiltration, which are depicted below:

1. Attacker injects malicious code into a vulnerable website – Cross Site Scripting (XSS)
2. Genuine user navigates to the vulnerable website
3. The website sets cookie and also responds with malicious code
4. (a) The malicious code forges user’s request to same server – Cross Site Request Forgery (CSRF)
   (b) The malicious code steals the cookie and exports to evil server – Exfiltration

The main goals of CSP scheme are: Control over content inclusion, Enhanced security against XSS, Preventing data exfiltration and ensuring backward compatibility. By comparing CSP scheme with steps in the above pic, we can see that CSP can control Step 1 (XSS injection), Step 3 (Content Inclusion) and Step 4b (Data exfiltration), but does not address Step 4a (CSRF attack). Also, Scriptless attacks (via HTML injection) and Self-Exfiltration attacks are some of the cases which are arguably beyond the scope of CSP. Let us discuss them one by one.

Cross Site Request Forgery (CSRF):

The core problem in CSRF is, server cannot differentiate between requests originating from two different origins. e.g., Consider the code in the below snippet (Ok, no bank does a simple GET for funds transfer. This is just to make my code slimmer). Given these two requests, a server would not have enough information to know who originated each of the requests.

//Genuine HTTP request from bank.com:  
<form method="GET" action="https://bank.com/transfer.aspx?from=ALICE&to=BOB&amount=100">
//Forged HTTP request from evil.com:
<img src="https://bank.com/transfer.aspx?from=ALICE&to=MALLORY&amount=10000"/>

There are several comprehensive tutorials on how CSRF works, so I do not intend to cover it here. Though there are defenses such as generating unique anti-CSRF tokens on the server, it is not a robust defense, since if the token is stolen, requests can be forged and back to square one.

Though people use “Referer” header for checking where requests originated from, it is shown that it can be stripped easily and hence not a secure solution. The more robust “Origin” header is the suggested option to prevent CSRF. Please refer one of my old posts on Referer vs Origin headers.

It is easy to imagine a CSRF defense in CSP headers. Before triggering any unsafe (impactful) cross origin request, a page can do a preflight request to a server and get its security policy (whitelist of allowed sites). So a CSP supporting browser will not do unintentional cross origin requests to origins which are not specified in policy file. This is somewhat similar to HTML5 CORS preflight handshake. However, triggering preflight request for every cross origin request results in network latency and degrades performance of the web. CSP spec authors have evaluated this option (check CSP’s Request-Source directive) and moved CSRF defense out of CSP’s scope. Since the work on Origin headers was proceeding simultaneously and it proved to be robust, Origin header check on the server is considered to be ‘the’ solution to prevent CSRF. Hence, this is the reason why CSRF defense is out of CSP’s scope.

Scriptless attacks a.k.a HTML Injection:

In his blog post titled “Post cards from the post-XSS world”, web security guru Michal Zalewski explains several markup-injection vectors, which can be used to redirect forms and steal content. Strongly recommend you to visit his blog post, which is a valuable source of information. Since CSP rules focus on scripts injection and content inclusion, they allow markup injection, which can bypass CSP defenses.

One argument which can be made here is, markup injection and node breaking attacks are more of a parsing issue than a genuine security policy issue, but similar argument can be made with respect to XSS filters as well. The chances of a successful markup injection are low since it requires code in the web page to be organized in a specific way, which is not required for script injection.

Self Exfiltration attacks:

A recent paper by Carnegie Mellon University researchers shows a set of attacks called “Self-Exfiltration attacks”. Though the vectors they explain in the paper are more or less HTML injection vectors as in the above section, the idea of execution of the attack is tricky. Most modern websites such as youtube.com have data which is private as well as public. e.g., profile information is considered to be private data and is visible only if a person authenticates himself, whereas, comments are visible to all public without the need for authentication. So the idea is, if by some means data can be moved from private region of a website to public region (comments), an attacker can simply visit the comments and steal sensitive data. Note that since data moved between different regions within the same origin, CSP rules do not come into picture.

Trusting whitelisted sites:

This is an issue with which we have been living since ages and nothing specific to CSP. When a website embeds scripts from external sources (mashup scenarios), the security of the site translates to trust between the site and foreign script owners. Though CSP narrows down the possible scripts in a webpage to that of a whitelist, it does not eliminate the trust factor. If foreign script sources collude, they obviously have full access to DOM, network, client storage of the website and can cause damage. In short, trusted whitelist of scripts does not necessarily mean total security.

While it is difficult to see the practical implementation of these attacks, if it is possible in theory, it would not take much time for black hats to put them into practice. Hope this overview is useful in understanding the scope of CSP better :)