CSP Analysis - Attacking XSS Mitigation

so okay okay so yeah let's get started um before i get started uh let's um finish the stupid questions first does anyone in this room not know what cross-site scripting is and i feel really stupid asking this sorry okay um i assume everyone does great so uh my talk is on csp analysis or content security policy anyone knows what it is content security policy okay we'll cover that um so short introduction to yeah it works perfect to myself my name is frederick i'm 24 and i'm from munich i work as an information security officer at chip digital some of you might may know the site chip.de it's multi-german you can find all the examples on the

source code of what i'm showing you here on hashtag security.com csp so if you want to check that out please do so and you can ask me questions anytime later or on twitter at hashtag security okay so um content security policy is basically an http header so if you request a site you get a response from the server and the server sends your in the response sends you a http header that says example here defcon.org they have csp enabled and as a content security policy default source self which tells your browser you're allowed to load sources like javascript files like style sheets images stuff like that only from our server they could specify from facebook.com or from wherever you

want but basically it's a whitelist so the goal is a cross-site scripting mitigation so you can't just specify from evil.com give me all your cookies.js you can't include it if it's not here in the csp um so obviously that's a nice thought but it's not enough to mitigate cross-site scripting just wide listing sources because if you have a cross-site scripting vulnerability you could just add your own code in line so what csp does besides white listing sources is it blocks all inline javascript so if you enable csp on your site it will probably not work anymore i know i guess a lot of you guys have a website that uses javascript and probably not everything has been moved to javascript

files and included but sometimes there's just the typical script called script text and then javascript in between right in the uh dot php or dot html file so this won't work with a csp enabled um other stuff that doesn't work oh yeah sorry to make it work as i said you need to move it to a script file and include it like this um other things that won't work is all evil functions are blocked um evol is evil everyone should know that here um don't use it if you have csp enabled you could enable it on purpose that's like opening all ports on a firewall uh kind of destroys the the purpose of csp and another thing

which most people uh interested in interestingly enough sorry about that uh don't know bar my function equals new function uh that kind of declaring function in javascript doesn't work as well it's blocked by csp and you can't enable it the reason why most people don't know this is because most people actually don't uh take a look at the request for comment but they just go for blog posts and it's not mentioned in most of the blog posts so you might run into problems with that okay yet another thing that is blocked by csp and you can enable that as well is inline css so if you have anywhere on your site something like this and header line one

uh headline one tag with the inline cascading style sheets like font color equals red this is a basic cross-site scripting example we have an unsanitized user variable and we can just add anything after bob and what i did here is i added the one the header one line with a style font color equals red and as you can see the header defaced is added but it's still green because bio csp of course html is not blocked that would be disastrous but css is blocked okay you can see all the violations to your security policy in your browser which doesn't help you that much if a user comes to your page and browses it and stumbles across a csp violation

but that you can set up actually a report uri where all these reports from all users are sent to and you have detailed reports in a log which is kind of nice it's supported by almost all browsers yeah i guess that not internet explorer these are the only guys who haven't implemented it yet at least not fully they have some features but it's very experimental and not really supported by ee um actually i tested it with ee ie 11. it doesn't work so they're still behind there okay so the question what is csp it's frustrating it's really frustrating to implement it you're gonna really gonna have a hard time doing it and if you do um please do your research first

otherwise you will break your site and uh angry people will be at your desk definitely um so the question i want to answer here is it worth it if it's frustrating uh do we really want to put that much time and effort into it for that i want to take a look if it actually does what it says it does so i gathered all the information i could find on attacks on csp and tried them each one by one and let's take a look at that so we have injecting javascript of course sorry encoding javascript of course there's always a way to try to bypass stuff by encoding it we have injecting into server side files

if we can inject into the files that are on the server most uh content security policies state that our own server is fine of course why why wouldn't they so if you can inject into those files then you're in the clear if you can upload malicious files of course that's another great way to do it um or if you can just manipulate the csp header itself okay so first up this is actually interesting because we're not encoding the javascript to bypass the csp so in order to hide that we're using javascript we're just encoding it so we can put it in the url field without breaking anything and the meta tag is an http tag and is

therefore not blocked because csp can't block html i'm sorry html um so what we do here is http equivalent fresh we telling we're telling the browser of our victim to refresh the page not any page we tell it refresh the page base64 and that's our javascript base64 encoded and one what the victim's browser will do is it will take the base64 string decode it and execute it so we're not on the side with the cross-site scripting anymore but we're still able to execute javascript and the in the victim's browser which which is at least something okay so that's the the most basic attack um another attack of course is trying to inject into the javascript files

themselves so if we have to move everything from inside javascript to out of line or inline javascript to out of line javascript how can we inject directly into these these documents so i tried some stuff i tried evil which is blocked but i tried it anyway i tried var my function equals new function which is how i stumble across that this is blocked and i tried with the help of a colleague of mine parrot node insert this actually works i'm not going to show it here because it's just a bunch of code and it's not that interesting as i said i have i've put all uh all of the content all of the code examples online

you can you can check that out if you want it's really really awful code so if you you shouldn't stumble across this so the last example you shouldn't stumble across this uh type of vulnerability in the wild because we we really put a lot of effort into making this vulnerable enough for us to bypass csp so this was all on purpose and it still took us a lot of time if you do however if you take a look at it and if you find it somewhere in the world please tell me because if it's out there i want to see it let's hope not okay so um another server side injection is json because json much more obviously

it's used for storing uh data and for reading data from it so this is a basic php commenting system it is vulnerable i made it a bit more vulnerable not because i needed to bypass csp but because it's more convenient that way i don't have to think about encoding stuff it's just as an easy example so you can just store type in your comment posted and it's stored in the json file what the json file looks like is the first line these are two comments in the json file so you basically i think you have a laser pointer here you have your text a field and then first comment which is here and then you have the second

comment and what we want to do is we want to close the json with the square bracket add our javascript and then open a new for further comments what this does is it gives us valid javascript and valid json so nothing breaks um if we just use this one so if you the the highlighted the gray highlighted area it would just post this as it is uh jason will when json code is called uh will encode it and what you get essentially is a comment like this but you've not broken it because it will escape all double ticks so it's not going to work if you try to execute it what we can do is utf-7 encode it and i

actually never worked with utf-7 before this so that was something new for me um what you get is this exact same payload is now this string and if you if you take a look at it there are no double quotes no double ticks in there double quotes right so it's not escaped so we can't just uh inject it and this is the exact same string as will be stored in the json file so it's not been altered so the first three dots are just the first two comments i've stripped them away for better readability but this is exactly what we get if we take the whole json file and utf-7 decoded so everything that's been stored in the

json file before and is uh decoded utf-7 won't change so it's still the same thing um so that quite uh that works quite well if we include it have the script tag source equals and then our comments.json file and then type equals application javascript what uh what chrome will will tell us is you can't execute json files as javascript it's not going to work because you have strict mime type checking enabled and that's not um not allowed so what firefox says is this well that's quite interesting um i have to thank you a bit with it uh actually firefox gives you this response only on firefox 4.1 4.01 and below uh the reason for this is

mozilla stripped all utf-7 support from firefox 5 and above to be html5 compliant it still tries to execute the json though it just can't read it okay so that brought me to another idea if it takes anything you give it why not try to upload that image and there are a lot of uh vulnerabilities out there that think you're uploading in an image because it's called.jpg so what what else could it possibly be than an image right so this is a really really basic examples i'm sure you guys can think of a lot uh a lot better ways to inject code into into images for this for simplicity's sake um we have a file called evil.jpg

actually it's a text file with alert one in it and suppose we can upload it to the server it's theoretically of course then we can just tell firefox if our victim uses firefox of course otherwise it will break to load this as a javascript file and it will happily execute it i tested it on firefox 28 no problem so this is still an a possible attack okay let's get to the last part uh who here knows what crlf injection or carriage return line feed injection is okay basically what you have is you have a new line thanks um and this the character's percentage zero d percentage zero a which tells this is the end of the line

and now comes a new line um what we do this the the code above is basically an hd a php redirect page so all it does is it takes the url parameter and tries to redirect it to this source and what you can do is you can call the site i call it reader.php and url equals site this is our site with the cross-site scripting on it you can add the cross-site scripting parameter if you can add them in the url and then just percentage zero d percentage zero a and don't put a line break in there it's just uh for better readability because otherwise the line would be too long this is actually one line um add your

uh header option which you want to to add to the response from the server like content security policy equals script source unsafe inline we're just allowing uh inside inline javascript to be executed so we're telling the csp allow inline javascript which is as i said before much like the allow evil function bad never do it on purpose depends on the side you're on um right so what we do is we add two crlfs at the end and tell the browser header and everything that comes now just forget about it this is the end of our header um it works on certain machines depending on the php version you have installed because php actually fixed that problem

it still works even though php fixed it in some versions of internet explorer but i don't tested them because internet explorer doesn't support csp in the first place so why bother there wouldn't be any gain of it so it still works um but aside from php having that vulnerability fixed it's still a uncommon vulnerability so um this is just an example which has been fixed in the meantime but uh there are still a crlf injection vulnerabilities out there and if you stumble across one and there is a csp in place you could use this kind of attack to bypass csp which brings me to my uh the end of my talk um does it work

and for me csp does uh definitely work that looks strange um because all almost all of the attacks if they still work rely on other vulnerabilities to be in place so you have the crf vulnerability that needs to be in place you have the file upload vulnerability that has to be in place in order to bypass csp so if you have a secure site and only only cross-site scripting on the side yeah secure side and cross-site scripting in the same sentence um then it's not gonna work except for the meta tag but uh there's nothing csp can do about that because it can't block the html meta tag and once the refresh is done it's not on the side and you're not

on the side anymore that's protected by csp so it's kind of a way around it okay so the other question is is it worth the hassle and that's really for everyone else to figure out i can't tell you yes or no for me it's definitely worth the hassle i know how much work it is and i know how much of a pain it can be but if you take the time and if you get the resources of course for doing so it can help you because it not only blocks cross-site scripting attacks and gives you time to fix them it also if someone stumbles across it by accident and doesn't even realize it you get a report and you know that there's a

cross-site scripting vulnerability and you can fix it so for me it's worth it okay so that was my talk as i said you can find all the source code and the examples along with detailed explanations on hashtag security.com csp uh you can ask me questions now later or on twitter at hashtag security um i want to thank my mentor dave for helping me and also a colleague of mine who isn't here today uh scott for helping me with the javascript the evil evil javascript and thank you all for listening and for having me