Mike is an editor of the Content Security Policy specification, which is a mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS). Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources.
Yes, first Content Security Policy would allow you to embed only the widgets that you actually want to embed. Really embedding a 3rd Party Widgets is kind of cross site scripting yourself and what you would want to do in the policy that you create is allow scripts from those particular sources, so if you want to load a Google+ button then you would whitelist the origin from which Google+ serve script and then you would whitelist the origin from which Google+ serves an iFrame. If you whitelist both of those origins then you’ll be perfectly allowed to load the script that loads the iFrame and then load the button in your page. You simply need to construct the policy that allows you to load this specific modules that you find important. You also mention Sandboxing which is quite interesting because there is an attribute on an iFrame that allows you to reduce the privileges that that iFrame runs with. Generally speaking an iFrame is just like at top level container of the top level window, it has all the permissions of its origin. With Sandboxing you can reduce that, you can actually say that new script should run inside this iFrame, the plug-in should run inside this iFrame, it shouldn’t be allowed to navigate the top window and so on, so there are number of things that you in order to reduce the privileges that a 3rd Party Widget runs with on your site, you certainly be able to do that with CSP with Content Security Policy and you should also be able to do it by Sandboxing iFrame itself.
Generally speaking we say script can execute and that means script can do anything on the page, there is not currently a mechanism by which we say that like WebGL is enabled but nothing else is enabled. You did mention Connection so ever and Connections are something that Content Security Policy can absolutely control, so you look at things like XMLHttpRequest’s EventSource, API’s and WebSockets, all of these are controllable via a connect source directive and Content Security Policy so you say that your website could only connect to these particular origins because they’ve serve data for your website, you want to connect to those but you don’t want to connect to evil.com for instance.
I can certainly imagine stuff like that having some sort of value. I don’t really think it would have much security value over. In Content Security Policy is really about wrapping up a number of directives that influence the way that Content can load your page with the goal of making your page more secure. Forcing strict mode in script might be an interesting thing to do but I don’t think it’s something that really fits with the general model of Content Security Policy.
I gave actually a talk on this couple of weeks ago at CSS Conf EU, so maybe we can put a little of into that somewhere, I think that is good. It’s an interesting topic because people don’t generally expect that CSS is as dangerous as Script, people look at Script and cross site scripting and say: “Well, as long as I just turn off JavaScript, then everything is fine”. It’s actually quite possible to do some very interesting things with CSS, or you can attack people without Script, without Script of any sort. CSS gives you the ability for instance to examine the value of attributes on a page by using attribute selectors, so if you have a csrf.token on your page you can actually read the value of that token by bruteforcing with CSS by using an attribute selector on the value attribute. You can then exfiltrate that data to a 3rd Party or send that data to a malicious Party by loading background images, so CSS gives you the ability to A: fairly granularly read data on a page and B: sent that data to malicious 3rd parties, so it’s more dangerous than you’d be expected to be.
I think transport level security is really important, it’s more important than you’d expect, because basically if you are sending data over HTTP there is absolutely no guarantee that the data that you are sending and the data you are receiving has anything to do with what you actually send and what the server actually send back to you. We kind of conceive of the web as direct connections between my laptop and a Data Center somewhere. The web really works quite differently and we know that, we hop and hop, from server to server until we actually get toward destination and hop and hop to get back, so if you want to trace route, you see like 17 servers in between you and your destination. If you are sending data over an HTTP unencrypted and unclear you have to trust each and everyone of those points in between you and your server you are talking to.
It’s absolutely trivial for a WI-FI network that you connect to for instance, to manipulate the content of websites that you are visiting because there is no guarantee when you connect to CNN.com do you actually getting today’s news, the WI-FI network or anyone in between can inject things into the page add worse or they can simply read the things that you are reading and store information about you. HTTPS gives you a measure of security in that is certainly not perfect but it’s really the only mechanism we have of giving you any sort of guarantee what so ever, that you are A: talking to the server you expect to be talking to, like I’m talking to example.com, it gives me a certificate and I can verify this certificate. B: the information that you are sending and the server is sending back to you is intact and it sends without manipulation from 3rd Parties and between man-in-the-middle-attack. And finally it gives you some measure of privacy in that the actually pages and you else that you are loading are not visible outside the context of this encrypted tunnel.
Yes absolutely, one of the really interesting features of Content Security Policy is Reporting. It’s very interesting for a website owner to know that are under attack or to know that there are holes in their sites where content can be injected and that it’s being exploited actively by someone. Content Security Policy gives you not only a mechanism of creating a policy for a page but also allowing notification when that policy is violated, so if a Script is injected into your page, Content Security Policy will block its execution and will also send a post out to a reporting service you specify. The post is basically JSON, JSON block the contains, a bunch of information it will be useful for you to try to track down exactly what the problem is to gives you that you are out of the page where the violation occurred if it comes from JavaScript we are trying to give you like a line number and a column number that you can try to figure out exactly where the violation occurred and try to figure out what you can do to mitigate that risk or to block that particular entry point.
What is also nice about Content Security Policy is that you can run both a report mode policy and an enforce mode policy at the same time, so you can have a really lax enforce mode policy that you know your page meets and you can have a much stricter report mode policy and you can use this kind of a role out mechanism or you slowly crank up the strictness of your Content Security Policy by first deploying it as a report only mode. Looking at the reports that are coming, fixing the bugs on your site where your site doesn’t actually match the theoretical policy that you expected to, and then once you are not getting reports anymore or once that you are only getting reports that are actual attacks, then you can flip that over into an enforce mode policy, such that is actually applying to your page and actually blocking things.
Generally speaking Content Security Policy should be sent as an HTTP header so that is synchronous with the load of the page and the script doesn’t have the chance to execute before Content Security Policy is applied. You can however also inject the Content Security Policy after the fact by injecting a meta tag, so if your page is set up in such a way that you need all sorts of dangerous things, you need Inline script, you need e value, you need a variety of other things, what we were seeing some people do successfully is basically boot up their application, load all the code they need and then inject the policy that blocks any additional code for loading.
Dio: Using you mean meta tag so there is syntax for that.
There is syntax for that, it’s only supported right now in Web Kitting Chrome, it’s however part of this CSP 1.1 specification, so imagine that Firefox will be supporting that as well, as well as other browsers that want to pull in Content Security Policy.
8. That goes for everything CSP?
Correct, the browser support for CSP is relatively good, Chrome has supported it as an unprefixed feature for quite some time now. Firefox 23 and up support Content Security Policy and the new versions of Opera that are based on Blink also get the Content Security Policy implementation and my expectation is that WebKit, the new versions of Safari 6.1 and 7 should I believe support Content Security Policy as non prefixed header, is certainly in WebKit, I just don’t know what version of WebKit is going to come out with those browsers.
First let’s say there are quite large sites that are using Content Security Policy right now, so Facebook is probably the best example. They’ve deployed a relatively strict policy and they are having some success with that. GitHub is using as well, Twitter is not only using it but there is also very involved in the sentence process and propose some interesting things for 1.1, so there is certainly both engagement and interests from this sort of large sites that I think were all interested in protecting as best we can. To the question of constructing a policy for these sites, when you know you are going to be changing the things you load on a regular basis or you simply expect change in your sites. It be really good to embed Content Security Policy or creation of the Content Security Policy in your built system in someway. If your built system has an understanding of the resources you load, that will be the right point at which to construct a policy for the page.
What is interesting about CSP is that because it’s delivered as an HTTP header each document on your site could have a completely different Content Security Policy. You probably wouldn’t want to do that by hand but if you can integrate that in some way in your built system or you can integrated in some way in the construction of your page on the backend, where ever you have an understanding of the resources that should be loading on the page, you can construct a policy and deliver just for that page, so your homepage might load completely different resources than an article page in the middle of your sites. Giving that, constructing different policies for those pages would be a good way of ratching down the permission so the page only loads the things that this type of page needs to load. That make things more complex rather than less complex so I guess the answer to your question is that you would need to build some internal tooling along with your sites that has an understanding of the resources that are loaded and use that to construct a Content Security Policy.
Yes absolutely, Content Security Policy 1.1 is currently a candidate recommendation in the W3C. I edited the spec along with Adam Barth from Google and Dan Veditz, from Mozilla, and there is a lot of interest from other parties as well. So we are already to the point now where 1.0 should be implemented in browser, so there is been already a call for implementations and we are in a process now of developing a test suite to verify that all the browsers should be doing the same thing. 1.1 is being developed concurrently and there are some interesting changes to 1.1 that we think make the world a little bit better for developers. The biggest change I think is inline script. Content Security Policy 1.0 gives you the ability to either turn inline script on or off, and we suggest you turn it off because inline script is really where most of these content injection attacks, become problematic. Turning inline script off entirely over is difficult for a lot of sites to do because a lot of sites have reasons for using inline script, it might performance, you might want the first load of your page to be absolutely fast as possible to get something on the screen and maybe you need inline script for that.
We are developing something on 1.1 such that you can widely specific inline script and give the browser the ability to distinguish between scripts that you wrote and scripts that attackers try to inject. There are two mechanisms that are looking at: the first is a cryptographic nonce which is basically a one time pad you generate, so you generated a random string when you generate a page, you send that as part of the policy and then you embed that same string as an attribute on script tags that you actually want to execute on your page, so this might be nonce 1 could be your nonce which wouldn’t be very secure because it’s easy to guess, you want to generate something nice and random, but if was nonce 1 you would sent nonce 1 in the header and then you would have Script Tag, Nonce equals, nonce 1 and that script would execute other scripts, so if an attacker inject a script it would hopefully not have the nonce because the attacker wouldn’t be able to guess it and that script would not execute. So that is one mechanism by which we could enable inline script. Another mechanism is Hashing, and Twitter has a great proposal for Hashing, we are evaluating right now, the idea there would be you send a SHA hash of script in your policy, so you have a long hash and then any script on the page that matches that hash would execute and the script that doesn’t match that hash would not. Hashing is a little bit more difficult that it’s sounds because you have to worry about encoding, and white space and a variety of things, so we are working on a lot of details but that seems like a very interesting proposal and between those two I’m pretty sure there will be able to deal with inline script in a much more granular way than we are now. There is a number of other changes in 1.1, we are rolling in things like the X-XSS protection header so that turns on the XSS auditor in WebKits and there is a similar functionality in other browsers as well. Currently that is a completely proprietary header, we are specifying that in rolling in to Content Security Policy. There are a number of other more granular headers or more granular directives that are being put in but I think there is probably the most important.
Generally speaking you can hand roll the stuff, the policy definitely needs to be hand rolled or you need to build tools that roll it for your site because you have to have a good understanding of the resources that are actually being loaded. That said I know that there are some modules that it’s being put out, I know there are Railsmodules that Twitter put out Twitter put out called I think Secure_Headers, I’ve create a name, and that makes it easier to construct the Content Security Policy and tries to do some work to normalize the policy between the unprefixed header, the standard header and then the previous attempts at standardization which were the prefixed headers and both WebKit and Firefox, so Firefox had x-content-security–policy and WebKit had x-webkit-csp. So Mozilla originally invented this a while back before moved into the W3C, the syntax was a little bit different and the functionality was a little bit different.
That is not relevant today to modern browsers but if you need to deal like Firefox 4 then anyone who want to use CSP, then you are going to have a slightly different syntax and slightly different understanding. This module tries to take a set of rules and build this policy in both of these styles. I wouldn’t actually recommend doing that, I think it’s easier and safer if you simply send the standard header. Generally speaking enough browsers support that, that you get kind of heard immunity, so if you are using Reporting then with like 50% or 60% of browsers that supports the standard header, you are going to get reports from them, you are going to see holes in your sites and you are going to be able to fix those holes for everybody. Sending the standard header to a browser that doesn’t support it, basically doesn’t no harm and certainly makes the configuration easier on your sites, you are not doing like user agent sniffing or something like that.
Dio: So you would be basically doing some sort of sampling and it would be enough to find security policy.
More or less, and you would have a more than a representative sample by sending the header and you need also be protecting those users that are using modern browser. The users that you’d be worried about are the people that are using old versions of Firefox, old version, well any versions of Safari right now. So I’m hoping that those browsers, well the old Firefox is getting away, old IE is never going away, but we haven’t yet seen an implementation of Content Security Policy from the Internet Explorer team and very helpful for the features and is a standard that they are participating in, we just have not seeing an implementation yet but I imagine that is coming and as I said I think WebKit already has a 1.0 implementation so I expect that is being rolling out as well.
Is a really interesting paper by, guy name I forget, Michal Zalewski who also works at Google, a really intelligent guy. It’s called “Postcards from the Post-XSS World” and he is started to put together ideas of how you can be attacked once script is no longer allowed on site, so once every site deploy as a Content Security Policy blocks all sorts of content injection, blocks cross side scripting attacks, what is left? What sorts of things are still open into us? And there is more than I’d like, it’s unfortunate but the web is built in such a way that it’s kind of insecure by design. It really is an open system and wants to share information and wants to make it easy to share information.
That is generally a good thing but we are getting to a point now where we are not just dealing with academic papers that wants to be distributed, we are dealing with things like your bank account information that you want to keep as closely to your heart as possible. The things that were coming up with, so Content Security Policy is a good example, are mitigating factors. They don’t make you safe, you still have to do a lot of work on the server side in order to make sure you are escaping everything correctly, there is still a lot of work to be done to practically solve these really simple problems of just escape content and put it out correctly. We are able to create mitigating factors, we are able to mitigate the risk and make it less likely that you can be exploited. It’s going to be very difficult to get to a point where we can remove that risk entirely. One of the proposals in this paper is that we move from a model where we send down text that is that is then purse by the browser, so we send markup, the browser purses the markup and then build its own parse tree Michael in this paper suggest that it might be nice if instead we send a binary representation of the site, so instead of allowing the browser to construct a parse tree, the server constructs a parse tree and send it to the browser and then the browser would know that is getting this correct information from the server.
I don’t even think that is a good solution or a perfect solution, because you can just trick the server into generating new parse tree, so I think the problems are deep and the problems will continue to grow. What we need to do as developers, is grow with the problems and make sure that we are using the new technologies that are coming out and new standards that are coming out to continually rise the bar and make it more difficult for attackers to attack us. A good comparison I think is address space layout randomization in operating systems where instead of having the same block of memory mean the same thing every time, you can move things around to make it more difficult for attackers to be able to jump to things that will be useful for them. That doesn’t solve the problem of malware, but it certainly makes it more difficult and if you don’t randomize your address space, then you are just making it much easier for attackers, and I think the measures that were coming up with now are kind of like that. They definitely rise the bar, they make it much more difficult for you because if you can’t just inject script into a page, then it’s still possible for you to perform attacks but it’s much more difficult for you to do, so when you have to analyze the particular web application and figure out specific holes for that as suppose to find anymore broad things that will make your life more easier. So I think the web in itself is a difficult thing to secure. All we can really do and what we must do is continually raise the bar.
Dio: Thank you very much Mike!
Thank you!