NovoGeek.com - Krishna's weblog

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 :)

Tags: web security, browsers

In my previous post, “The uncontrollable web platform”, I have discussed at a high level the core security policy current browsers have (i.e., Same Origin Policy, SOP) and why it is insufficient to secure the modern web. As said in the post, researchers have put in lot of efforts to design stricter and smarter policies.

Several policies like BEEP (Browser Enforced Embedded Policies), SOMA (Same Origin Mutual Approval), Browser Enforced Authenticity Protection (BEAP), MashupOS (from Microsoft) have been proposed to fix the gaps in SOP. However, each of them had one or more problems with respect to real time implementation. In 2010, Mozilla proposed a new policy called Content Security Policy (CSP), which is the closest fit for current security problems. The goal of this article is to introduce CSP and highlight its importance.

The CSP Scheme:

As explained in one of my posts “Securing the web with Declarative HTTP security policies”, CSP can be added to web pages in the form of the response header which looks like this: “X-Content-Security-Policy: script-src mysite.com; img-src:*”. The primary goals of CSP scheme are as follows:

Control over content inclusion:

The CSP scheme provides website administrators control over the content which can go into a web page. As seen in the example above, if script-src is set to “mysite.com”, all external JavaScript files can be loaded only from “mysite.com”. So recursive script inclusions which is possible in the current browsers relying only on Same Origin Policy will not be possible in future browsers implementing CSP. Similar configuration can be done for images, frames, objects etc.

Preventing data exfiltration:

In the current SOP scheme, cross origin requests such as <img src=””> can steal sensitive data and export it to evil destinations. This is known as data exfiltration. CSP gives security assurance to the visitors of the site that sensitive data is not exfiltrated (sent out) to evil destinations. Before triggering cross origin requests, browsers check if the outgoing origins are present in CSP whitelist. If they are present, cross origin requests are sent, else cancelled.

Enhanced security against XSS:

CSP does not allow inline scripts to exist in a page, because of which a large section of XSS attacks can be reduced. Of course, as pointed out by Michal Zalewski in his blog post “Postcards from the post-XSS world”, HTML injection based attacks are still possible and are outside the scope of CSP.

Clickjacking protection:

The best defense so far against clickjacking attacks is X-Frame-Options header proposed by Microsoft and it is implemented by all browsers. Though it is a great solution to prevent framing altogether, CSP offers better flexibility. Administrators can decide which sites can frame their site, apart from denying framing completely. So Clickjacking is better defended by CSP.

Backward compatibility and only tightened security:

CSP scheme is backward compatible. i.e., if a site having CSP headers is opened in an old browser which does not support CSP, no negative impact is seen. Security is only enhanced if browsers have CSP support, else users have the same level of security as they have with SOP.

Now that we have seen the CSP scheme, let us see the rules on which it is based.

CSP Base Restrictions:

1. Disable the execution of inline scripts

   In the current browser architecture, there is no way of differentiating between scripts which are genuine and part of the page vs. scripts which are injected via XSS holes. CSP attempts to bring this differentiation by disabling inline scripts altogether.
   
   By disabling the execution of inline scripts, XSS can be mitigated to a large extent. The downside of this approach is, even genuine code such as event handlers, code between script tags, javascript: URLs will not work. Considering the dangerous effects of XSS, this tradeoff can be easily opted for enhancing security. Since inline script execution is disabled, CSP enforces that all JavaScript code should reside in external “.js” files. This separation of concerns is also good with respect to accessibility, code maintenance and performance.

2. Disable the evaluation of code in strings
   
   As Douglas Crockford rightly points, "eval is Evil”. The eval function is the most misused feature of JavaScript. It can be used to evaluate the code inside strings, which is very dangerous.
   e.g., The code eval(String.fromCharCode('97')+"l"+"ert"+"(1)"); throws alert(1).
   So one can imagine how easy it is to obfuscate strings. There are alternate forms of eval which can evaluate strings. e.g., Funciton, setTimeout, setInterval etc. CSP disables evaluation and execution code in strings, which is a major step in disabling the execution of malicious code.

CSP Directives:

The base restrictions get applied by default in a CSP supported browser, when CSP header is configured in a website (this default behavior can be configured). Apart from this, CSP also has “Directives”, which determine how a browser should behave when it comes across protected content. Some of the directives supported by CSP are:

• script-src: Requests which will be interpreted and executed as scripts
• style-src: Requests that will be interpreted and executed as stylesheets
• img-src: Requests which will be loading images
• frame-src: Requests which will be loaded as frames in the web page.
• xhr-src: Requests generated by XMLHTTPRequests.
• media-src: Requests targeted by HTML5 <audio> and <video> elements.
• frame-ancestors: Which sites my embed the protected page as iframes (clickjacking protection)
• object-src: Requests targeted by <object>, <embed> or <applet> elements.

The list is exhaustive and is updating at a rapid pace, adding newer directives. Apart from these directives, CSP also provides a mechanism to report policy violations. When a directive “report-uri” is configured, any violations of CSP (attack attempts) are submitted to that uri so that administrators can act accordingly.

Example CSP policies:

X-Content-Security-Policy: allow ‘self’ (Requests for all types of content should come from the same origin as that of the site)

X-Content-Security-Policy: allow ‘self’; img-src *; object-src media1.com media2.com *.cdn.com; script-src: trusted.com (Requests not configured by CSP directives are limited to same origin, images can load from any origin, plugin content can load only from the given media providers, scripts can be loaded only from trusted.com.)

X-Content-Security-Policy: allow https://*:443 (All contents should be loaded over SSL to prevent eavesdropping on insecure content)

Conclusion:

Content Security Policy (CSP) fixes the loopholes of Same Origin Policy of browsers by introducing content restrictions in web pages. It helps websites specify what content can be loaded and from where, prevents attacks like script injection, clickjacking, data exfiltration etc and provides early warnings to administrators. Having said that, a site should not depend solely on CSP and should have their security mechanisms still intact, since CSP is not supported by all browsers currently. As browsers mature, CSP will be a good first line of defense.for the web platform.

References:

• “Reining in the Web with Content Security Policy” by Sid Stamm, Brandon Sterne and Gervase Markham, WWW 2010.
• CSP specification: http://www.w3.org/TR/CSP/

Tags: web security, browsers, JavaScript

On the web, every other day we see a new JavaScript library, a new framework, a browser hack or an innovative way of using/bypassing some feature for building something good. Most of us are so deeply involved in learning, constructing new things that we almost forgot, failed to care or understand that the core of web platform is beyond our control. The situation is not that bad that someone can hack your site immediately irrespective of your defense mechanisms (as hyped by a few ‘so-called security experts’ and tech magazines), but for sure, there are a lot of loopholes in place by design, which security ninjas understand well. As Paul Irish (Google Chrome Developer Evangelist) points out in his blog, in the recent years, academic researchers have been concentrating on enhancing the web platform and browser security is gaining a lot of traction.

The goal of this post is to point out some of the gray areas in the web platform and how browser security is shaping up (some of you might already know these in pieces). The post is intended to bring security focus to web developers so that it enables them to understand cutting edge research going in this area. As a part of my M.S by research thesis, I am lucky enough to survey and study the state-of-the-art research going in this area.

JavaScript and access control

Web developers, specifically lovers of JavaScript (JS) know very well about it’s ‘bad’ parts along with its magical powers. Leaving the bad parts and security of JavaScript language aside, the other issue related to JavaScript security is, what access privileges can a script running in a web page can have? There two main security features which restrict the damage JS can do in a browser are – Sandbox and Same-Origin-Policy (SOP).

Sandbox makes sure that JS in browser does not have access to the underlying file system (Imagine a malicious script which made way into your webpage deleting your files!). It is due to the restrictions of sandbox that one cannot do file I/O operations using JavaScript.

Same-Origin-Policy:To understand and define SOP better, one needs to understand the term “Origin”.

Origin: The combination of “scheme://host: port” is called the “Origin” of a website. Scheme stands for protocols like http, https etc. Host stands for domain name such as example.com. Port is the port number on which the protocol is running. For http, the default port is 80 and is not included in notations.

As per the above definition, http://example.com is called an origin. Note that http://example.com/profile/kris.php (dummy link) is called a URL whose origin is http://example.com.

For all major security decisions inside the browser, “origin” is considered as a basic unit which provides isolation. Thus JavaScript’s access control  (even in HTML5) is defined in terms of access to origins.

Same and cross origin interactions

Same-Origin-Policy controls the interactions that can happen between origins. Interactions like read/write/execute on “resources” are granted access within an origin whereas restrictions are put across origins. The below table shows clearly what are same and cross origins.

Note that the sub-domains mail.example.com and chat.example.com are treated as different origins though they have the same parent domain. This restriction can be put off by a feature called “domain relaxation”. By setting document.domain property to “example.com”, both the sub-domains can reduce the origin check to “example.com” instead. There are a lot of intricacies of course, which I do not want to cover here.

Note: Michal Zalewski’s book “The Tangled Web” best explains in detail, the intricacies of origins and browser security. My understanding of web security has multiplied after reading this book. Also, the core concepts in this post are compiled from some of its chapters. Suggest you to read the book for increasing your depth.

So the interactions between sites whose origin do not match are known as cross-origin interactions while between those that match are called same origin interactions. These interactions vary between various resources of the site. Here, the term “resources” refer to DOM (Document Object Model), Cookies, XMLHTTPRequest (AJAX), HTML5 Local storage etc. In general, SOP can be stated as - Within an origin, all scripts have equal and complete access to DOM, storage and network, whereas across origins, they cannot. It is observed that the implementation of Same-Origin-Policy in various browsers varies with the resource in consideration.

Now that you have understood what same origin and cross origin interactions are, try to answer the below questions yourself. To set the context, let A.com and B.com be websites from two different origins. Let A and B be the the content of the sites A.com and B.com respectively, rendered by browsers. Now,

• Can A get resources (images/css/scripts) from B.com?
• Can A execute resources (scripts) from B.com?
• Can A post content to B.com?
• Can A interfere with the DOM of B?
• Can A redirect a browsing context (iframe, window etc) of B?
• Can A read storage (cookies, localStorage etc) of B?
• Can chat.A.com communicate (exchange data) with A.com?
• Can A.com/user1 read/fetch content of A.com/user2?

Though these questions look trivial, they bear a lot of concepts behind. I have written several blog posts related to the above questions in this year (2012). Check these:  JSONP and Cross-Origin AJAX, AJAX vs. HTML5 CORS, HTML5 Sandbox, The need for HTML5 PostMessage, Frame Navigation Policies.

Why is the web “Uncontrollable”?

Though Same-Origin-Policy enforces certain restrictions on the way script interact, it has several bypasses and is not sufficient to meet complex security requirements (e.g., mashups are the best example). Below are some of the cases which are beyond the control of SOP.

Content Inclusion:

All HTML elements which make HTTP GET requests can be loaded from any origin. Ex: <img src=””>, <link href=””>, <script src=””>. SOP does not put any restrictions such as preventing cross origin inclusions. For the past several years, this has been a security concern since browsers do not do anything when it comes to inflow of content. Also, nothing stops an image tag from downloading a script. As Douglas Crockford, JavaScript guru, rightly points, “SOP does not apply to scripts themselves”.

Moreover, when it comes to scripts, there is recursion involved in some sense. i.e., a script can in turn create another script tag in the DOM and load a remote script. So if a script “X” is trust worthy, it does not imply that the other scripts “Y” and “Z” loaded by “X” are trust worthy. Trust is not transitive and cannot be verified in this model.

Cross-Site Scripting (XSS):

As most of us know, XSS is a technique in which attackers use flaws in web applications to inject evil code. Typically, code injection happens due to lack of (or) weak sanitization of inputs, either before storing into database or before rendering into the DOM. Based on the way XSS is triggered, it is classified into Stored, Reflected and DOM XSS. OWASP.org  has detailed information on XSS along with a few detection and prevention techniques.

The point here is, once a script is injected, it has equal and complete privileges as other genuine scripts in that origin. So DOM access, network access and storage access is compromised. SOP does not have anything to say about XSS, which is a major problem.

Cross-Site Request Forgery (CSRF):

In this well known attack, the attacker masquerades as a genuine user and submits HTTP requests to the server. The server assumes the request is from a genuine user and executes it. A simple image tag can be used to send cross origin GET requests, thereby forging the genuine user. (Check OWASP.org for more info). SOP does not have any restrictions on out-going requests or a mechanism to identify genuine/malicious requests and hence fails to prevent CSRF.

Data-Exfiltration

Data can be sent out to cross-origins using several techniques. Apart from image, script, link tags which can do cross origin GET requests, HTML forms can do cross-origin POSTs, because of which sensitive data can be exported to evil destinations. There are several hacks which can export data (out of scope of this topic) and the main problem here is lack of check on out-going data. SOP does not have a mechanism to check data-exfiltration, which is also a major concern.

Conclusion

In principle, data can be pulled in and sent out via several channels without any security checks by browsers (Authentication and authorization come under application logic at the server, not on the client). Due to these main factors, the state of the current web is uncontrollable. To fix these problems, security researchers are focusing on designing stricter browser security policies, which address the limitations of SOP. The main challenge here is, web has already grown into a huge tree and any drastic change will break it completely. Backward compatibility with respect to supporting older browsers, older languages, developers who are not ready to migrate etc. are a part of this grand challenge. However, the work of several smart researchers is beginning to pay with smarter and stricter policies coming into picture. I shall discuss them in my upcoming posts. Stay tuned

Tags: web security, JavaScript, HTML5, browsers