now this is very policy is a new feature in browsers that's currently supported in Chrome Safari and Firefox and there's partial support in Internet Explorer now we don't boo browser vendors we like we want to support the wall make them all awesome so the goal of content security policy is to help mitigate cross-site scripting vulnerabilities if you've built a large website and had mean people come to your site and try to hack it you will be familiar with this problem the general approach for content security policy is a bit different from other techniques for stopping cross-site scripting so most previous techniques either focused on like on server-side frameworks or on like JavaScript escaping techniques so content security policy is a bit different in this model what happens is the website declares to the browser policy for where its scripts and other resources are expected to come from and if the website loads resources or scripts from somewhere else the browser blocks it so the idea is if the attacker tries to load Z load his script the script won't be on the websites policy and the browser will stop it and there'll be no no attack so in that sense it's a white listing based approach where you whitelist the scripts and content that you know to be good in the world and then things that aren't in your whitelist hopefully won't be running and things that are in your whitelist will hopefully not not hack you it's meant to be a defense-in-depth technique so you shouldn't rely on content security policies your only line of defense you should do everything you're doing today to protect against cross-site scripting you know input sanitization output escaping all that kind of stuff this is just another layer to help you secure your website more so as for availability 1.0 Konda security 1.0 is available today it's in most major browsers as I said the support and Internet Explorer is partial and we're hoping in Internet eleven that they'll complete their implementation there's a 1.1 version which I'll talk about a little bit at the end of the talk and that's under active development right now and so we're adding some features and refining some things and if you have feedback about content security policy or things you'd like I think we could do better or change that that's great to do as part of the 1.1 effort to do the next generation of this stuff so I wanted to first start with an example of a policy just to give you a feel for what this kind of stuff looks like so the policy is delivered in an HTTP header so the browser requests your website you send back the HTML then in a in a header along with your HTML you supply the policy so the reason the policy is supplied in the header is because that's hard for an attacker to forge it's sort of a good trusted communication channel to communicate the policy from the server to the to the client and then you can see that the policy here is a sequence of directives so there's a default source directive which is sort of that's the default so here it says self which means by defaults allow allow me to load resources from my own origin from my own website and then you for different types of resources you can be more specific or override the default policy so here in this policy for images I've said the the sources star which means anything anything goes and I've written this because images you know if I load a malicious image into my page it's not the end of the world like life is not going to end it's part going to be you know not ideal it could be like a ugly picture that I don't like but it's not going to steal my users data here object this is like the object tag or the embed tag that you use to load plugins so here I've said that I can get it from these two different media hosts or from the CDN and then scripts I have limited to just this trusted scripts com domain and so no other scripts can load in my page except if they come from from this site does that kind of make sense it like a high level yeah good yeah ah yes you can actually specify a directory and then it'll say only from that directory you can also specify a scheme or report or that kind of stuff if you leave off the the scheme it sort of picks a good one so if you're over SSL or HTTPS it only allows HTTPS if you're over HTTP it'll allow HTTP or HTTPS but you can you can always qualify it to be more specific if you want so generally the different SRC directives correspond to different HTML tags the correspondence isn't perfectly like one-to-one so like the object source means like the object tag also counts the embed tag because the embed tag in the object tag are very similar so this is really about like plugins plugins can come from from these sources and like image isn't just the image tag it also includes like images that you load in your CSS basically generally it's mostly images but also other yeah that's a good question so oh sorry the question is how are all these rules process is it the like most permissive one works is it the last one that the browser sees so within a given policy the default sets up the default and then the more specific directives override the default but you can also if you were having fun you could send many many policies so like you can have six headers and have six policies and then something is allowed only if it's allowed by all the policies so it's a way of tightening things down the because this is a security feature generally we err on the side of defaulting towards security so if you're setting multiple policies maybe your server is making a mistake or something and so we don't we don't want to maybe one of the policies is coming from the attacker or like something weird is going on so we'd be concerned we're conservative and we say well they all have to be have to pass all the policies does that answer your question so these I mentioned you can control different types of resources these are all the different kinds of resources that you can control I don't know why I put a big picture of Yoda here oh I think I was thinking about like use the source but that doesn't really make a lot of sense anyway I wanted to focus on a script source for a moment because that's that's the like key key directive if you want to block cross-site scripting it's really about scripting the other stuff is sort of allows you to fine-tune if you're you're into into the details so yeah the script source directive controlling the source of script is really the key to blocking cross-site scripting if you think about it cross-site scripting is really about executing the attackers script there are other sort of variations of in other ways of thinking about it but in the end what makes a cross-site scripting attack and attack is that the attacker is executing a script in your page and causing your page to do things it doesn't want to do you know potentially leaking information or showing things to the user that they shouldn't see or things like that and so the script source directive lets you whitelist scripts so list out exactly where the scripts can come from that are allowed to execute and no other scripts are allowed to execute and this so the idea is you will say I want to get scripts from my source maybe you like to use the Ajax API so Google hosts for a jQuery or something and maybe you have a CDN but that's it so like for example you're probably not going to put the attackers website on your list I mean you could yeah yes there's face delimited yeah the directives are delimited by semicolons but the individual values for a given directive or just space delimited yeah yeah picking the syntax was a little bit hairy because you want it to like fit well in an HTTP header as you and you also want like fit well and like HTML attributes so we're a little bit shy on like punctuation yeah yeah I mean it depends how worried you are about the attacker injecting different headers generally I don't worry about that too much so it's not super important like what order you send your headers or where in the header you put put these things because generally generally I would I would take the view that the headers are going to get delivered find most of your injection vulnerabilities are going to be in your HTML or in the body of your of your response well generally HTTP headers get sent first before like HTML tags so if you actually load your scripts that comes in the body of your response and so that comes after these directives it is possible by the way you don't have to supply it in a header you can supply in a meta tag but that's not as secure because you could mess up before you put that meta tag yeah I don't recommend using IP addresses but you can I mean it's fine you can also mix star and IP addresses which will do weird things but you know we support it why not yeah so like you saw earlier that we can have like image source star which said give me images or anywhere well we let you say scripts or star but you might not want to do that that's probably that idea that says I'll take scripts for anywhere it kind of defeats the point yeah yeah so I would say that our general philosophy on this topic is something we call the priority of constituencies so that means as a browser vendor different people have competing interests and the question is how do we balance those competing interests so like one person who has a competing interest is the person who develops deloused the browser so people who make browsers and so we're pretty low on the like the priority of constituencies somebody like the author so the person who makes the website or the person who supplies the policies is pretty high in that priority but even above the author is the user the user is actually using the browser so they have the highest priority of constituency so generally if a user wants to modify how website works as a sort of philosophical point of view because the user has a higher priority of it as a constituent we view that they should be allowed to do that so this doesn't prevent users from modifying scripts that websites apply no sort of a long-winded answer to your question yeah and related to that so users also have extensions in their browser so this we try really hard to make it so that the websites policy doesn't interfere with extensions we don't always succeed and if you read people who've given us feedback about content security policy in the past people written blog posts and such you'll see that they were sad that they deployed CSP on their website and then people as extensions broke and so we tried harder and now we're better at having CSP not interfere with extensions there was a question yeah you can although our goal is that it works automatically that the extension author doesn't have to worry about it so for example we automatically whitelist resources loaded from extensions we don't we allow those because we believe that they're they reflect the users intent these are good questions I'm very excited about this questions ya know if you have a header the meta tag is ignored and if you have a meta tag the first one is taken and then the rest sort of signor so the the meta tag is really for cases where you can't use the header like in a file or something so what happens when when say you try to run a script that that isn't listed in the policy so the browser refuses it says I refuse to load this script from evil calm because it violates the you know directive that said only load scripts for myself and from like api's or whatever there's also an event that gets generated in the Dom so you can listen for that event if you want to see and then there's also a reporting mechanism over that reports back to the server that I'll explain later why don't I put this here oh yes I remember so okay so this is a script that comes from a URL right so it's like super clear what the source of this script is it's from my own website I decided to use angular if I put self in my policy it's clear that this script should execute everyone's on board with that what about this script where did this script come from yeah so you said HTML source you said no origin from what yeah so these are all sort of good questions so do you think that we should include this in self do you think that's a good idea so what yeah yeah somebody can screw with your HTML and inject script into the HTML see yeah exactly did everyone hear what he said would you like me to repeat it I repeated so what he said is is if you recall earlier I said that we sent the policy in the header because we had high confidence that that data was really coming from the server and reflected the server's intent but once we're down here in the like body of the document things are a little bit more murky if there's an attack going on and the attacker is able to inject stuff into my page maybe he's injected this so maybe this reflects the attackers intent and not the server's intent and so if we whitelisted if if the server said self i want to execute scripts that come from me and then we get this we don't know whether it really comes from the server or maybe is coming from an attacker who's injecting it that makes sense yes good oh did someone have a question ah yes so you can if you so there's a separate token oh I I tricked you because I put it on the slide after you asked your question yeah so there's a separate token which says inline which means allows scripts that are that are in line but you might notice that we put the word unsafe here in the front and that's meant to be a hint to you as the developer that maybe this is not the most secure thing to do yeah so these things that come in quote marks are key words so as distinguished from things that aren't coded which are like you know host names so one of the things we notice is that not a lot but a sizeable fraction of extensions and cross-site scripting vulnerabilities in them and those are sort of pretty nasty vulnerabilities because if you can cross-site script into the extensions context then you can do all the things that the extension can do which is sort of a lot so what we did is we actually revved the extension system we went to version 2 of the extension system and then like we cleaned up a little like odds and end but the main difference between version 1 of Chrome extensions in version 2 of Chrome extensions is that in version 2 we actually enforce a content security policy by default and in particular we enforce one it's a little bit long because it has a bunch of details in it but it doesn't allow cross-site scripting and then since we've done that the incidence of cross-site scripting in version 2 extensions it's like it's not zero that's like still possible but like close to zero yeah so generally I would recommend that you I'm not like performance experts so I you know police take performance recommendations I'll give you with a grain of salt but I think it makes sense to combine your scripts but you would have to do it as it and out of line script not an inline script that's actually what most people do when they do this stuff yeah haha you are you guys are a great audience so give me give me two slides okay well give me two slides I'll get there anyway so this is my sliding clay in case nobody got the could this be from the attacker you know so this is like supposed to be like PHP where you're just like echoing the users name into an HTML context and I really enjoy this xkcd comic about little bobby tables so if you have a little bobby script tag or something you could be in for a bad time I think everybody should print out this come back and like tape it to their their monitor or something to remind them of this yeah so what do you have so what you have to do so really really what's going on is you're separating your code and your data so if you hang out in security circles you'll find that people repeat various phrases over and over again like principle of least privilege or separation of code and data as like general like high-level security principles and so really that's what's going on here by moving your inline script out of line you're separating your code which is the script from your data which is your Dom or your HTML okay one more slice oh and you should do it a sinker there's ways of loading scripts as fast okay this is your question right yeah yeah okay so what about these these kinds of things so these are inline event handlers so you can have a button and you can say on click and you can write some code here and this has the same problem as a inline script block in the sense that an attacker could be writing this code because it's part of the body of your document so inline event handlers also count as inline script and you you have to remove them to use content security policy so generally frameworks help you do this so for example this is how you might do this in jQuery you would instead give the button a class you would select it and you'd bind a click handler or listen for the click event but yeah any kind of selector you want yeah so the idea is that this this is part of your script and this is your data and they're separate and the concerns have been separated post load binding so jQuery is is does a nice job with this I think other frameworks do as well I just happened to my slides happen to be jQuery base so what's cool about jQuery is you can actually bind these events before the elements exist so that's what this live keyword means instead of bind so you set up the query and it says later on if someone happens to create a button in the future that happens to have this class and it somebody happens to click on it please call this motion and so generally you can build an event map and then have the Dom come and go and not have to worry about actually finding the nodes and poking at them other frameworks that are more more modern than jQuery have like even fancier ways of doing this I think it's generally considered a good practice these days to like not use inline event handlers but to use some more structured representation like a class or an ID and a more structured event map you might disagree that sort of a matter of opinion but but yeah this too is also in the sort of issue of separating code and data generally if people who've deployed CSP and work with this stuff this hasn't been a big sticking point for them this part has been pretty easy removing all the inline script has been more of a sticking point and I'll talk a little bit about how we're hoping to help that in in the future so eval is also a way that you can get cross-site scripted if you have an untrusted string and you pass it to eval now you could be running the attackers code so set timeout also has the same problem if you pass a string to set timeout it gets eval essentially but so instead of doing that you should just pass a function and that doesn't get eval that just gets called as well function that's a very easy change to make anyway so the eval thing is optional it's disabled by default if you are controlling scripts so if you have a script directive but you can turn it back on with unsafe eval I would say that that unsafe inline is more unsafe unsafe eval is not such a big deal if you wanted to keep keep using eval in your code but I'm keep in mind that it is a vector where you could get cross-site scripted yeah so here's my four step program to mitigating cross-site scripting move your scripts out of line get rid of your inline event handlers if you're feeling ambitious get rid of eval if you're not feeling ambitious you can skip that step and then add a script source directive to your content security policy easy right we should all know maybe it's a little bit work so with you saw earlier there's a big long list of directives if you were feeling paranoid and you wanted to control more than just script there are lots of knobs you can turn to have more control so there's a short section in my talk where I tell you how to do that if you're feeling ambitious so the default source directive is the one that helps you there so you're going to set default source to none and now you have a very secure website that would not have very many features you probably wouldn't want to use it but you can start with something more sensible like by default load things from myself and then refine it over time as you find that your have resources that are blocked so here's a policy from a real real site this is a garden Ematic website that I wrote a little while ago so here I started with with default source none because I was feeling ambitious and figured I should try this stuff out for myself and then here are all the different like kinds of resources and where they come from you notice that I did use the unsafe inline key word for style so I can I have a style block that has stuff in it you know maybe maybe that maybe that words you maybe he doesn't depends on how paranoid you are you have the ability to control it to turn it on or off as you choose yeah you can see that I use fonts fancy fonts everyone should use fancy fonts so here's my cheat sheet that says what each of the directives maps to so for example media maps to both audio and video because they're closely related generally that's not worth controlling them separately and that sort of funny one is connect source so connect sources like the grab bag of if you have a JavaScript API that loads resources so like XML HTTP request or WebSockets or workers or whatever all that kind of stuff those are all controlled by connect source generally those are not such a big deal but if you want to control them the options there it's at your at your choice okay someone asked earlier what happens if there's oh did you have a question Chrome extensions do not allow you to have unsafe inline scripts yeah if they did then they would open they would allow developers to open themselves up so it's a yeah on the web you have more choice if you want to be a powerful extension in chrome we give you a little bit less choice because we're worried about you endangering users so I mentioned that when your web site violates a policy there's an event that gets generated in the Dom that says you this element try to load something that violated your policy we also you can also specify a report URI so there you give a URL and then when there's a violation the browser will send you this JSON blob to that URL and tell you something went wrong so it's like this document that was referred to by somebody trying to load this thing that was blocked because it violated this directive and then here's the whole policy that wasn't being enforced and so the idea is that you can use this to see if you're causing trouble for your users so you can get feedback about how well your policy is working if there's some corner of your site that like maybe you don't have the policy quite right on or maybe if you're being attacked maybe that the reports will give you some sort of early warning that there's an attack going on and this speech feature is actually very popular this feature is so popular that there's actually a report only mode which says here's a policy please just tell me reports about it I don't bother blocking things yet and so that that's you also have both you can have one that's enforced and one that's being in report only mode yeah yeah so it's good for a honeypot it's also good for just testing so suppose you were interested in in CSP and you wanted to use it on your website but you were afraid of breaking your website then you could try report only mode for a while and then see how many reports you get and then if that number gets low then you could turn it on for real and you would sort of a softer deployment path okay so this is my summary of content security policy in 1.0 so its goal is to mitigate cross-site scripting it does that by white listing content especially script to use it you have to do some work on your site you can't just apply it as is you have to really separate your code and your data so that the browser can tell where all the code is coming from so that involves moving your inline scripts out of line removing the inline event handlers and ideally removing eval but not not really required and you have default source if you really want to be secure by default and go the like paranoid lockdown route you can get violation reports which is feedback from the field about how that how well this is working and this is as I said it's implemented in Chrome Firefox in Safari there's a partial implementation in Internet Explorer they implement actually a directive that I haven't even told you about yeah so I think what you're referring to is some people like the script tag but they don't put script in it they put data in it and so they'll specify a type like type this is my data this is not script and then the browser won't execute that script it will just leave it there in the Dom for something else to interact with and that works fine so here because the script is not executing it's not going to run afoul of any policy it'll just show up it'll be in line in order they won't violate any policy it'll just be fun so I have a couple more minutes so I'd like to briefly talk about the future of this stuff which is content security policy 1.1 so the biggest piece of feedback that we've gotten on 1.0 is that people wish they could use inline scripts and this requirement of like getting all of your scripts out of line is like really you know it's work like it's doable like definitely people have done it but it's work and so as an example here's the Google Analytics tippet they tell you to create this like gaq object so that you can like call functions before it's loaded it's like some fancy thing but the point is if you really want to do this the way it's meant to be done you need to this inline script so how can we solve this problem so the approach that we are experimenting with currently in one point well one is to use a nonce so if you're familiar with the idea of a nonce it's just a random number that you made up one day and you every day you wake up or every time your website is fetched you make up a new random number and the idea is that it's known to you but unpredictable to an attacker does that make sense so you can include in your policy that one of the places you can get scripts from is from people who know the knots and this is just some like random number I don't know how many how many how long it has to be that's like up to you you get to decide like how paranoid you are how how afraid you are somebody guessing this random number you made up probably if it's this long no one's going to guess it and then what do you yeah well make it longer mm-hm yeah so what do you do with this nonce well what you do is you take your inline script and you say I know the nonce here it is and this thing matches this thing and then because the nonce is here the browser can reason oh this must not be the attacker supplying this data because the attacker doesn't know the nonce so given that the nonce has been and associated with this script it's okay to execute because that's what it does that make sense yeah so this is this feature of 1.1 is like very popular people are very excited about this so they're also new directives in 1.1 that do various interesting things so like before you can only control plugins by URL and now you could you can control plugins by type so you can say I want to have PDF where I want to have flash but I don't want Java or Skype or whatever it is you like or don't like yeah yeah so that's a good question so all of sorry the question is I'm not sure I 100% understood the question but I think the question was what is the scope of a policy so when a site declares a policy what does it affect does it affect an individual page does it affect the whole site was that your question ah yes okay I understand the question so let me first answer the simple version that will answer the advanced version of the question so the simple version is the policy applies to a single document so when you supply a policy with a HTTP response it applies to the content in that response and the advanced question is maybe that's too coarse-grained maybe I wish that different parts of my page had a different policy so that's a request that people have made and we haven't figured out a good way of doing that yet so if you have ideas for how you think we should do that I would encourage you to come to the w3c working group and and present your ideas and try to get people on board okay yeah so CSP 1.1 is under active development if you're interested in this stuff and you want to share your experiences with 1.1 and tell us what we did well or poorly and what we should change in 1.1 this is the mailing list of the w3c so it's the web application security working group we have a bunch of browser vendors there we have much of website operators there we would love to hear more feedback if you want to play with a CSP 1.1 in Chrome you can turn it on in in the flags so you turn on experimental blank features yeah but if you want to use 1.1 that's stable and like ready for use in production thank you you