Fixing XSS with Content Security Policy

all rights my name is Sydney admit Riva and we are talking about content security policy today and specifically about how we can fix cross-site scripting avoid cross-site scripting protect from cross the scripting using content security policy can you guys yep closer whatever sure um I know there was not a talk about content security policy today and they were talking mostly about securing content and not talking about cross-site scripting so it's a couple words so I'm a associate principal consultant at digital I was like working with security for over five years before that I was a developer and in my free time I do ballroom dancing I was actually came straight from Belarus as have a competition in a couple of weeks

but so this is what we are going to talk about today what is content security policy just kind of refresher why do we need it why did we come up with it what is how does it help to to fix cross-site scripting and we'll talk about the details of like version 1 and version 2 of CSP why version 1 wasn't adopted as quickly as we expected and what we're changing in version 2 2 to hopefully have it adopted so first we'll talk about cross the scripting anybody familiar what it is yay all right so there are so cross the scripting in general is a vulnerability in the web application in the front end in the way

you are interpreting the input that she receives from the client from the user and reflecting that input usually you know displaying on the page at some point without validating the input without making sure this is what you expect and so the input may contain JavaScript usually you know when we talk about well but javascript could be like vbscript or some other script that's running in the browser so the script is injected into the page then the browser execute sit and it's just like any other injection right just like command injection just like sickle injection the browser doesn't know that this data is supposed to be just data it says the word script this is the other

JavaScript keywords and runs it right and because the script came from somewhere who we don't trust it could have been part of the URL it could have been stored in the database you know the script may contain malicious actions and because it is being run inside the company although the inside the clients browser the person who is logged into the website so the script has access to all the data that this person has on that website they are you know account numbers their personal pictures data application forms item so there are three different types of cross-site scripting the first one is reflected this happens when the payload is usually part of the URL goes to this server and

then it is reflected immediately in the response so it's executed immediately it's in the response it's run by the browser the script is executed another type is stored when the payload is not reflected immediately it is stored somewhere on the server database file any persistence layer and it will be retrieved at some point even the attacker who's storing that saving that in the database doesn't know when exactly is going to be retrieved they just canna store some stuff and hope that somebody will view this page and the script will get executed so for example it could be a blog post right you're writing the blog post the blog post doesn't have any filtration you inject JavaScript and leave it there and

when this blog post is viewed by somebody and this somebody is logged into the platform then you can steal this person's information right for example they are you know login credentials their session for that blogging platform however a few years ago I mean it's been a while five years ago with all the new technology with all the new website web side client-side frameworks a lot of JavaScript that is processing the data on the client side we now have a new type of cross-site scripting that is called dumb ways right the DOM is the document object model that's the representation of the HTML page in the browser so in this case that malicious script is executed completely on the

client side now the first two we have something going to the server the server stores it checks its manipulate somehow and then shows on the response in the Dom based case all the many pollution is happening in the browser and that's because the way the javascript is written right it's not a developer has to make a mistake first right has to leave that vulnerability open because the JavaScript for example grab something part some part of the URL does so many puree shins with it and then shows in the page right especially with all the single page applications where everything is done in the browser that's becoming more and more common so how do we traditionally fix cross-site

scripting well we always say input validation and output encoding the two main you know main protections from any type of injection so input validation we know what input we are expecting if that's a phone number if that's an address of that's an email we check we validate the structure and we say yep you know it's a phone number so we're expecting only numbers etc etc if we cannot do input validation for example like a blog post right we don't want to limit the users to use only certain characters we say yeah you can use whatever you know less than greater than semicolon all the special characters sure so we're going to do álbum coating on the server side where we say yep this

output is going into the browser so we're going to use specific context yep it's going to be HTML we're going to encode it with HTML coding so that the browser when the browser displays those special characters the browser doesn't execute them as a command right browser just says okay this is a less grant less than angle bracket right so going to show that angle bracket I'm not going to interpret it as part of JavaScript so that's all good and for years and years and years we were saying that input validation output encoding has to happen on the server side because you control the server you don't control the browser any validation that you have on the browser

can be disabled by the user finally we kind of figured that out well now we have the Dom based cross-site scripting that is completely in the browser so everything we're doing the server is not going to help us because it most of the cases the input doesn't even travel to the server it just stays in the browser so you can have all your you know validation input validation of encoding and they're still going to be a problem so what do we do well one way is to do same things input validation opera encoding but on the client side as well when you know that you have that logic in the front page tedious right and I

mean even with the server side validation we've been doing that for years and years and years exercise was first part of two of top 10 in 2003 it is still in the top five in 2015 so like we weren't very successful in fixing it obviously how are we going to be successful in fixing another time yeah there's like always a way you can close one thing it close another thing but there there's still way to bypass that input validation right so let's look at some examples of how that happens anybody rights java script reads javascript yeah all right all right some JavaScript samples with some Java code so for example on one type of an

injection where we have an inline JavaScript right so this is our JSP page we get a parameter from the request right get parameter s some parameter from the URL string and then when we arrive at the response in the HTML page we reflect it right away where if like the search word right away and as usually you know you search for something in the next page says here are the results you searched for this right so we are expecting a search word what we're getting is something like that yeah script alert exercise script so that's obviously yeah just a simple simple Java scripts not malicious or anything just going to pop up an alert box but because there is no validation

that script alert scrip becomes part of the page and when the browser interprets that says okay this is a tag p which means this is a paragraph this is a text script which means everything after the script i have to execute so that's one type of injection that's called an inline JavaScript injection right we inject the JavaScript into the HTML page so another type can be when we say okay maybe the search word has a limitation of how many characters you can write that's legit says okay in hundred characters so maybe hundred characters is not enough for us to write a long malicious JavaScript but it will actually go and you know steal your session data or forward due to malicious

page and ask you for username and password something like that so another approach is to inject a link to a script that is loaded from somewhere else right so same stuff on the server side but instead of injecting script alert script we are injecting script and then we're specifying the source that this file will be loaded from attacker com it will be load it it will become part of the page and will be executed and that's one thing about the way the browsers work so they have a protection system that's called same origin policy where scripts from one origin and origin is your domain name with a port with a type of connection HTTP HTTPS well in one domain

cannot read the data of another domain like when you open your gmail and you have some ads on the side can the ads read the contents of your emails I hope not right so yes because the the ads are loaded from another domain the same origin policy protects them from just going and reading you know the console via emails however the script is an exception you can specify you know for example this page is loaded from example.com but you can specify whatever website whatever domain in load whatever JavaScript you want it will become part of the page and will have access to everything on the page so that's the second type of how we can exploit that

injection right the third type is an injection inside our JavaScript so JavaScript has this wonderful wonderful function that's called evil that whatever string text string you pass into it's going to execute it as JavaScript code makes the language very very flexible however it's a great tool for the attackers because whatever attacker sends into evil you know that's just a code execution right and it's just going to run it so in this case suppose we already have that code snippet in the application where we are reading something from an element called parameter and we want to evaluate a function that we have and pass that whatever we got from the parameter our user input as a parameter to that

function so a malicious user instead of sending their you know first name what we're expecting are sending something like this again in this case we're just saying oh we're just going to send in a lower deck success but the point is that we can inject any JavaScript we want instead of the first name so and so that is the Donbass cross-site scripting it's all happening in the browser there is no request to the server side and obviously no response so there are different ways and as I said we were trying to fix it for many many years didn't work so we came out with a new solution right the browser group came out with a new solution

called content security policy where it says well let's tell the browser where we are loading all the resources from including the script and we say we don't trust any scripts that are loaded from attacker com we only trust scripts that are loaded from us and from you know a few our partners so that's one thing and if we look at this page right if we think about the attack surface for this page what are the different ways and attacker can exploit the page there is a form submit form right we can inject malicious data there there is some inline JavaScript if it has a vulnerability like domick success we can inject there there are some scripts that

we are already loading from third party domains so if those domains are entrusted if those domains were compromised now we can load some malicious script into our page there is a 3rd party plugins say flash there like there's an iframe all of these things can be used to make an injection and common security policy specifies certain directives saying okay you can only load scripts from this location the connect source will tell you you can only connect using a web service on WebSocket call to these websites to these specific domains you can only use fonts from this location iframes see it styles for CSS images media etc right object for flesh and silver latin applets and plugins and

the most important thing say we're going to disable any inline script because if we go back the only reason why like one of the reasons why I so basically the as i said we say we're only allowing stripped from certain locations right so that's the now going to work because okay attacker calm is not in our whitelist and also they say we're not going to allow any script that's in line will stop executing any inline scripts and because evil is evil we're going to stop using evil so all of these things are disabled by default as soon as you start using CSP it's the way it is configured is the you set the policy on the server side as

an HTTP header and then the browser that the client is using has to support it and today all the major browsers are already supporting so that's that's good news so for example we are setting a policy that says okay we can also set up the default directive so by default all the sources can be loaded from self so from my website which is a example at home and from my domain com and all images can be loaded from star so can this page load and image from bbc.com yes right as its star what about this one with this policy can a page load a script from attacker com

so there is no script source right we're not specifying it but there is a default so since there is no script the default will work and default says from myself or from start my domain com right it does not list attacker calm so that policy will stop any script that's trying to be loaded from attacker calm and the next one can oppose you load a CSS file from WordPress why do you think yes

that's the correct answer

right so there is no style tag that doesn't say in it to us anything about CSS and by default the default is also not specified right and the by default default is open like by default you can load anywhere anything from anywhere since we didn't specify anything here yep you can load everything so that will work yeah another cool thing that CSP provides is that if there is a violation of your policy if something is still you know trying to be loaded from somewhere that you don't specify you can configure a reporting mechanism you can figure parser on your server and basically each time the policy is violated each browser each client whenever they load the

version of your website will send you err a violation report in this JSON format or some version of this JSON format I should have I should say so they will say this policy was violated this is the URL that was blocked and so you can see exactly where the attack was coming from like this is a very very powerful tool just to monitor just to see what attackers are trying to inject into your website and in most cases it's not going to be just the attackers it's going to be your normal normal functionality of the website because developers forgot to mention this script or this URL for the fonts or this URL for the image so which helps you to

basically debug and find all these missing things there going to be some information from the plugins that the a user has in the browser because the plugins will also try to inject something that fills valuable information there's one caveat that the browsers unfortunately are interpreting this very simple format slightly differently so the names of the the attributes are slightly different some browsers add extra attributes but it's still manageable so you can collect all this data and graph it use it for development for debugging etc so that's that's great even better what if you know when you configure the policy and you enable it and there are a few URLs that you forgot to put in everything is going to break

right what if you don't want to do that well you can configure the report only policy that's not going to enforce the policy it's going to just check if there is a violation it's because I'm going to send you your report but your website will work especially at the you know beginning stages as you are developing that you're just more you know starting to use CSP that's a great tool the report only and moreover you can have both headers you can have content security policy and content security policy report only on the same website so you're going to use a more open policy at the beginning say well allow everything or almost everything and how

about we start with this more restrictive policy and then collect the data is everything still working how many violations we have all right we fixed all the problems with the violations now we can push it into the actual CSP policy and as I said we need to remove all the inline JavaScript from there from our normal code is this easy well this is our kind of traditional the way we traditionally wrote java script or HTML right we have some page we have some script inside we have some functions we have some like a button we have some event handlers unload on click so now we need to get rid of everything we create a separate javascript file we

move our functions there notice that we have a function click handler set timeout which has some code in the double quotes so set timeout is actually one of the evil constructs function so it's using eval behind the scenes it's going to evaluate that you know console dot log logging something and then calling the function repeated after the time as it has come right when the the time the timer clicked so that's not going to work anymore so now we need to take this function put it apart make it into a separate function because we cannot use eval or evil constructs so we created a separate function that's called repeated tasks pulled out those tasks there those

calls and what's more complex is that now we cannot use any event handlers that's not great helpful like it it's really unlucky so instead of using event handlers what we can do is we create a document and we create events and we put an event listener and we say you know at event when dom counting loaded that's basically our own load function previously do call our init function initialization and also find that button and add it on click event to the button so add another listener so then our HTML will look like that kind of like in 1995 before we use all the extensive JavaScript right just just the static content in like one call to a JavaScript

function so that's actually very very tedious especially if you have an existing application with a bunch of event handlers and yeah it's like starting from scratch so that is one of the reasons why the adoption rates were not as high at the beginning right now all the major browsers are supporting it except in trying to explore although they say the edge browser supports it I haven't tested it but that's what they claim they say yep we're gonna support it full full you know completely so almost everything supports it except for things like opera mini I don't know if you're using opera on your mobile devices if we look at the data from 2013 right how many websites were using CSP

headers well out of a million top websites only like 269 used it a little bit more with other types of the headers because also just 2013 not all the browsers supported the CSP header as is some of them support it like like ie and still supports the X CSP header you know the WebKit browsers had their own header prefix with an X WebKit but you know more or less 200 something out of a million browsers that's really really slow really small pretty much the other interesting thing is that CSP has two more directives well suppose you're you know we decided to use CSP but you're using a library that is using eval function and you have to

use this library say it's jquery or something like that and you don't have the resources to rewrite it so you like well either my website doesn't work or i have to allow evil so what you do is you say i'm going to use that directory that says unsafe evil now all your set timeout functions set interval functions evil functions are going to work but I love how they called that directive they're saying well yes your allow evil but now you're unsafe you have to realize that and same thing with the inline script if you want to allow inline script because your cannot rewrite the whole application you say yep let's allow unsafe inline and in if

we look at the data more closely out of those 269 websites 500 served 257 we're using these two directives which basically made their website as vulnerable as they were before using CSP it's like what's the use of using the technology then so yeah that doesn't didn't work really however there are some companies that were able to use CSB one full blown and one of these companies was Twitter so they were very loud about it and they're like yep we implementing CSP they started with some small applications that they have like a mobile version of Twitter or some other helper applications and then the final is that yep the twitter also uses CSP completely so I decided to look at the

headers and the first CSP header that I see says script source unsafe inline on unsafe eval like really Twitter after all these buzz that you did and like that's as far as you could go so then I looked further as the side was still loading and they overrode that first header I don't know what that why they still have it there but they load another one and this is a beautiful piece of work because it's a script source and that's it right it has two other URLs ABS at Twitter IMG com maybe as a 0 2 mg the comp but that's it no unsafe eval no one's safe in line so they were able to do it thumbs up for

Twitter and notice they're also using the reporting mechanism the last directive here is report your eye and they're capturing all the all the reports the next company who is also loud about it was yell however if we'll look at their headers unsafe inline and unsafe eval is there that's as far as they could go which means yeah I mean they're using it to control the content but they're not protecting that use not using it to protect themselves from exercise and the other interesting thing that I found in this policy was the first directive the defaults or star like that's what it is by default why do you even need to specify it I don't know

yep um so CSP one not widely adopted it's really hard for existing projects it it's doable for new projects if you let's say all right we're going to start from scratch and we're going to use it and this is how we're going to write JavaScript and then you can use it but people realize that yep the first version doesn't really apply so the suggestions to the second one include different ways to still keep the inline JavaScript so that you don't need to rewrite the whole application but make it trust it somehow sign it and say alright I trust this piece of JavaScript it comes from my server you can execute it whatever else is injected don't try to execute it and

those things are nons sores and hash sores some other changes that they're adding is like you can now specify the policy in the meta tags instead of the HTTP headers I don't know what's kind of the use case or value the CSP is still a candidate recommendation as of july of this year so it's still being developed it is partially supported by some browsers because it since it's still being developed we don't know what's the final sender is but the latest versions of chrome and firefox support a lot of functionality from CSP too so what are these headers the nonce you know we in software security will like nonces will like tokens we say this is the token I

gave it to you if you show me this token later I know that I gave it to you I can trust you right so that's the same idea we're going to prepend each javascript just put another attribute and say okay this is the token that comes from the server and also add the token into the HTTP header so when the browser is executing the JavaScript you know rendering the page says okay I have this JavaScript let's see should I be allowed to execute it or not well it has this token let's see if the token matches to what else and as the HTTP header if it does the browser runs it if it doesn't the browser just ignores the JavaScript

or sends a validation request if you configure the report policy so that's good however from the developer perspective the question is we when and how do i add these nonces the nonces have to be different for each time you reload the page they have to be unpredictable you have to store them on the service well no you don't need to store them on the service side so that's a good thing because you just have two copies one on the JavaScript one and the HTTP header the good the good thought the easy kind of approach is that ok I'm going to interpret my page I'm going to do my business logic and as soon as I'm

ready to send the page off to the user I'm just going to go through all those JavaScript's and stick an ounce to each of them well the problem is if we think back about the reflected XSS where an attacker sends you a piece of JavaScript and it's injected into the response and then afterwards words you're attaching all those nonces well the response is going to be there already and now you're signing off on the piece of JavaScript that came from an attacker from somewhere else so the approach works if developers use it correctly but there is a way to use an easy way to implement it and you live the application vulnerable still so then there is another approach

the approach of the nonce directive oh and then another question if we have the JavaScript and we signed off and you say yep we trust that JavaScript but the script itself has a vulnerability like we saw in the Dom based will it fix the issue no right script hat already has the vulnerability somebody injects into that script rights you know extra javascript in the same script script block and since you authorize everything that comes between the script and script and you don't know that has been modified at some point the vulnerability is still there so when we need that integrity when we need to say I'm sending you these 15 lines of code

I can just run a small nap but the video will probably

let Speaker two MiG's all right so when we want to ensure that whatever page but in a column for sending to the browser hasn't been changed has amazing tempered with what do we do a security sign the home right my cash that's no thing we all usually do so another directive is a hash right we take whatever is in between the script script tags and do a hash and specify a 256 or whatever and send them hash in the HTTP header so again the browser absorbs the page sees that there is the pumping security policy and in specified script source sha-256 and here's one hash there is no national semester sees those hashes and says alright i guess i need to hash and

free sample script validating cash measures so takes a half the script it hash matches to one of the ones that you are sending here the jealous because executors if somebody modified the page of the way if there is dom base judge the hash not a match so the script when we walk so that's great again you have to you have to generate hashes it's next to us that we have to use some kind of let agree that doesn't war right the wrong library have to add them each step it's extra work but it's for sure protect your page from any injected gentlemen but still we go to the question like growth how do we write our

pages so that it contains the minimal amount of Junction and today we are lucky because they're there are already a bunch of frameworks that do that we all the data binding frameworks that allow you to rise your HTML page without any judgment right you just specify the binding off ok this is the username that is displayed this is the search term that we asked for that is displayed here we're going to bind into a certain variable outer model on the client side and the ball was in separate jealous your file and it's not together relation separated our our team so if you are using one of these frameworks most of them are JavaScript except Jack oh of

course then you don't need to re-write basically they all these records are supporting CSP out of the box and figure them even figure where you're bringing your Java scripts from the mic to die over so so that's good news starting in the application you want to UCSB use one of these frameworks

then so that's the question I have a list of really good resources about home security policy as it slides in Germany on the website take a picture organ green later so open to questions are not finished earlier but a few minutes the question

is more reason but is it this is something that needs a website bastard that's what the developer umbilicus I plasticity so I'm kind of wondering if this could possibly make sense to do it at base or quite the sort of deal with extended to a client side of trousers thinking you multiply seemed like it didn't biting a brick if you make sure that you're not that anything that's from any other website of visiting use a local CSP websites so there are plugins for that there's one plugin so Stuart Larson who also gave top Helen i wass California he has a plug-in called Casper so it's a chrome plugin where you can write your own CSP

and it's for that specific reason to test right what if i apply this ESP to this page and let's see how it works you can also set up the reporting mechanism and get the reports and kind of play with it but in general it works for testing playing researching purposes but if you want to set up that app for like CNN com you have no idea how many resources they're loading from all over the place so you're going to set it up and suddenly all the images and videos are not loaded right so yeah so it's a great tool to play around but developers have to be have to take that effort and responsibility to configure the Seas you

don't want to trust the users what they configure it so any other questions

what do you mean by automatically validate

Oh to try to like from the Tigers perspective so the question was are there any tools to automatically validate the policy basically try to find the vulnerable places in the policy right what else can we inject no I have not seen the tools for that but I'm sure like with a plug in it will be easier because you can test but ya know there are no plugins there it would be great for like burp or somebody like that invented that is yeah it's not a bad idea any other questions all right thank you everybody