 Thank you guys for having me here. I'm really excited. There's my second time in London and So I'll just get excited when you've been to London So hello everyone, my name is Dheeraj and today I'm going to talk about content security policy so we'll be discussing about a lot lot many offensive and defensive strategies to Secure web application and we'll also be talking about Security best practices which you can apply to secure web applications and with the help of Content security policies by adding an additional layer of defense Before we get started. I just a quick raise of hands. How many have heard about content security policy before? all right, almost everyone and How many of you have actually deployed CSP to production? All right, and without breaking the production No, I All right, great a Little introduction about me like who this random guy on stage talking about security. I Work for a company called wingify. That's in India. It's very well known for its AB testing Product that is VW. I take care of application security there and before moving completely into security I was a front-end audition Working with the angle to JS and money large R script And I also do open source stuffs like recently I published CLI that to read awesome medium stories without really letting your boss know about it And also I might maintain a list of comprehensive bug bounty programs on get up And I can also play table tennis with both of my hands switching in between It's kind of fun a Little more When I'm not writing code, I try to find one of the reason web applications And these are the applications where some of the application where I've reported security issues and Most of my attacks have been on the client side where you must have seen this little pop-up from the browser window and and So today's agenda for the talk is to understand what basically security is and why is it necessary and Before getting into content security policy We really need to understand what type of attacks it solves and more over It's like cross-site scripting and other injection tags and how to mitigate those attacks using CSP and how do you how do you deploy CSP without breaking production? And also we'll be talking about crypto jacking. How many of you have not heard about Clip to Jacking for? All right, so In the recent past actually the last week More than 4,000 websites got hit by crypto jacking where You know if you visit the website that's infected website the malicious JavaScript could actually run and mine crypto currencies in your browser and This practice of secretly loading JavaScript in your browser is known as crypto jacking or in drive-in mining Similarly and good some couple of months back wordpays wordpress blogs were known to have recording of user credentials and which is very dangerous because it acts like a Keyloggers and we were sending the credentials to some of their attackers and points security is important in most of the times which I have seen that Security is like an elephant in the room where everyone agrees to it, but only a few way takes it way seriously and Since the first time your app is compromised You lose most of your users. They no longer trust your app or you and security's always takes priority when some bad happens and Before that, it's always takes a backseat and most of the cases and especially when you talk about startups or who wants to you know create some Basics products so and interestingly one of the things where most of us developers think that security is all about back-end but actually with lots of framework coming out in JavaScript and Attacks happening on the browser level like crypto jacking, which I mentioned you cannot neglect front-end security and And you can see that JavaScript frameworks are like every new every day we have seen a new JavaScript frameworks coming out and So let's talk about Scripting so when we when we talk about any client side or browser level attack the XSX is the first one everybody that come to everyone minds and This is this so popular that I have known some person who have been doing PhD in XSX so it's so so so complex and it's and so some years ago where people used to disable JavaScript to mitigate all this browser level risk, but nowadays with With such new browsers we cannot Remove JavaScript to compromise with the user experience and that's the we have to enable all the JavaScript to on a browser and that's that's that's the wonder but he where occurs when basically your data become code or Your code becomes data and when I talk about data, it's mostly the data coming from an attacker who has bad intentions and So for example where you can see this Little script of code, which is loading and trying to load an image which doesn't exist and and using a non error attribute is be able to show a little pop-up and This little pop-up was shown on our website Uber.com and I'm sure everyone heard about that and this dashboard where I had reported this wonderfully a couple of years back where where I just try to set my name was this little piece of code and and when I try to When any other user tried to remove My project or my name or my cringe my user this this little pop-up would occur and similarly I Have reported the one abilities to some other websites like one of the interesting one I remember is a recruiter box which an Indian platform for Hiring hiding platform where I was able to inject in one every Malicious code using which I was able to take a job at any any any of the openings on their website And that's how cool and I would be able to place at some good company and It's not about The just the pop-up. It's more than that. It's basically attack users. It has access to your DOM It can hijack the sessions. It can steal the cookies or steal the informations and it can even record your sessions and Moreover, it can even lead to crypto-jacking and So a Typical reflected access X looks like this where someone send you a malicious code and You click on that and it would try to get all your cookies Which might also have your session cookies and send it over to attacker and this basically Cookie would let anyone if the cookie is having the session cookie and then it would let attackers to have control over your session So we'll be seeing a live demonstration how this one ability occurs so to have a complete understanding about it So I'm running a very basic a Wonderful applications where you have a search features to That's basically very common search features We can have find it on any website or any blogs running on WordPress or any other things And if you just try to say hey, hello, and it will just show you the output. So why don't we try something? else Where I've already POCs and if you try to do something else, it's sure a little pop-up and this is basically due to cross-site scripting and developers Forget to escape the user input and like I was mentioning When your data becomes code it can lead to cross-site scripting and This little piece of code becomes dangerous because when you share this particular URL to someone and They open this URL and This could put it could execute it and this is a typical reflected xsx where a user input is being rendered by the application and This is how xsx attack occurs Getting back to the slides So how do we mitigate such type of attacks so where we can have sttp only cookies which can Which can lead to We can make sure that your browser doesn't get access to those cookies. So it's very useful to put sttp only cookies for your session cookies sttp only flag for your session cookies and then one can do input sanitization at the Back end so that any malicious input doesn't occur but in this demo which we have seen the input was never going to the back end and this is basically a type of xsx that is dome dom xsx and it means that doesn't necessary to It doesn't help to sanitize input on the back end because the input would never reach to that and it occurs when The vulnerability exists because of on the fly creating dome elements and So that's the reason you have to analyze places where dome elements are created on the fly and The correct defense for xsx is to construct stml securely in a framework that automatically escapes untrusted user data and which would be followed by a good Dom sanitizer as a second layer of defense and but that's Really a problem because of Escaping cautious and different browser quirks. It's very difficult to get it right and Xsx is many much solved problem if we do all these right things but then people think that they understand JavaScript and It's kind of funny because it's true, right? I'm sure some of you must be wondering about this particular little piece of code and trying in your developer tools, but I would say it works and Now when we say that this is the problem we have condensic your policy and So let's get started with CSP. It's basically a Standard which allows you to define the sources loaded on your website. It can be set via HTTP response error is something very similar to HSTS and It can also be set via Meta tags, which is very useful in the cases where you do not have access to the servers for example get up pages and you would be able to Specify content security policies just using the meta tags and it should never be a first line of defense and because Xsx can Actually occur if you do not in deploy CSP very correctly. So it should always be a defense in depth strategy and CSP also has to be issued on every page because browser doesn't cash it's like for example in case of HSTS which is used through Deploy complete STTPS application and in CSP like in HSTS a browser would just store this information and The the website will always be loaded on STTPS no matter what user tries to load but in case of CSP it has to be applied every time on every page request and So because browser doesn't catch the policy And so CSP basically helps in mitigating cross-site scripting attacks and Securing form submissions where you know it allow restricting browser to send information to many other locations like Like in case of password managers, let's say if they are stealing your credentials and actually CSP can help in those scenarios where you know data exfiltrations can be really solved and And you can also mitigate click-jacking using CSP and the most interesting part is doing STTPS migration and which is kind of very easy for the application which are very Very old and you do not need to write some code to migrate and it can be really helpful in that So let's get started. How do you how do we add this security header? It's basically it's a response here where you can see the policy goes here and you can define Consent security policies with this particular header and it looks like this where You have set up particular default source as a self It means that it allows loading your four resources from the same origin So what same origin is we really need to understand here Self is same origin and the origin comprises of three components One is the schema. The second is the host name and third is the port and and if when we talk about same origin If any of these components is different, then it would not be on the same origin for example If there's a site called CSP awesome And if we try to compare with another site STTPS ESO origin it will not be on the same origin and when we say it's not on the same origin browser would not be sharing this resources like cookies or local storage and other information Provided by the browser So So there are certain type of CSP Directives which could help you to define CSP policy and the first one is a script source where you can define what? JavaScript elements you need to put inside your application the major risk involved in putting in this directive was to solve XX and the style source could be helpful in loading resources like CSS style sheets and the major risk is website defacement or stealing of information like CSR tokens and Image source can actually be a very risky where you know someone can send information to their own domain by appending the information the query pair arms and Similarly we have other source directive like connect source which is for XML STP request that is ejects and other web socket request to be defined by this and We have some other source directive like frame source which could be used for Loading the iframes in any insider applications and then we have font source to define your Fonts loaded on your website and then there was an interesting thing called default source Which act as a fallback when you do not specify any of the fetch directive when I say fetch directive which is always appended by hyphens src so in his in an example if I Fail to write script source it would it would the browser would look for a default source and that's how it becomes fallback so in this particular example where we have defined image source of the star and this is act as a wild card which allow so so in this particular case it allows any images except the blob data or file system schemas and So it's not advisable to wild card to use wild card unless you are very short about it And then we have other source expression like none so in this example We have said object source as none it prevents loading plugins from any source and when we say about plugins like flash or any other plugins which could lead to vulnerabilities and For example, we have tile source as example.com in this way you can specify certain domains where you Crush those domains and you can easily allow them to load the resources in your website so in this case we have allowed The styles it to be loaded from the specific example.com and if you want to specify more and you can keep them separated with the space and Simple policy looks like this where we have defined script source as self object source is none base you are as none and so This policy actually does allow external scripts which are not hosted on your domain and Also, it doesn't allow inline script elements where or like even handlers like in this case image on error and Also the object source says that It should not be able to host any any interactive content like I said before it's like flash or Then base you are I make sure that it should not break any scripts which are using the relative parts and This is kind of a very Some secure policy which you can start with But there are some bad ideas where people Try to put unsafe inline or unsafe eval and CSP by default doesn't allow any inline JavaScript And that's the basic idea behind preventing cross-site scripting attacks But so in this case where someone tries to Define unsafe inline or eval. They're actually allowing inline source of elements such as style attributes on click Scripts tag bodies or any eval functions, which is kind of dangerous And but there are some cases where you really need to have some kind of inline script for example You have some code like Google analytics code which can have some performant impact and you do not want to Move that file somewhere or do not want to load load it there and it has to be in line There are certain ways you can put those scripts and also the lag is some legacy applications where you want to Allow inline scripting then you can basically do things like putting them in the external files So that you can put as a source expression as self so it will be loaded on your own domain and Also, you can use other strategies like hash nuns or script dynamic and We'll be discussing that as well So when I talk about hash and you have a script called alert and you want to convert into a hash You have basically do a base 64 encoding of this particular hash and using a Shah algorithm Which could be 256 or 384 or 512 and if you give that expression it could Give you next and base 64 encoded value which you can put it in the center in the header And it looks like this and which would allow only this exact script that can be run In your browser and if you allow this and no other scripts would be allowed to execute so These approaches are some sometimes very hard to maintain when they say when you have more than 10 inline scripts and And you frequently change those scripts it's very hard to have back and forth changing the application and talking to your devs and The DevOps guy to update those headers in the server So we have another approach called nuns where you can define a nuns in your content security policy header and this nuns has to be cryptographically securely random generator and And it would allow any script with the nuns attribute Given us the same as the header the browser would be checking and allowing only those scripts which matches the nuns So This is how Twitter CSP looks like and even it could not fit my browser screen, I mean the presentation screen and This is where they are using the nuns approach and they're whitelisting all the Domains it's kind of you know You have it's very hard to make sure that these domains are very secure and no one of the occurs on those domains And it's very hard to do it right and so that we have something called strict dynamic and this source expressions provided in the script source it Basically gives a complete trust in applications where in this particular example where Twitter was Allying different source for font source media source Which were actually required by certain script elements and it could have been easily prevented with a strict dynamic and where you Basically trust a given piece of code and you allow them to do each and everything what they are doing and so that it basically allows you to not have a bunch of domains which could Get compromised and if you do not take care of them in the right way and so basically when you have a strict dynamic Source expression present it the browser would ignore the whitelistic domains and it will only allow the domain Which have having hash and nuns representation? So we have talked about these approaches how how these approaches are actually helping xsx. Let's let's see that so in this example where we have a Script source a cell and we are allowing a domain called api to google.com and When someone tried to inject a script which is coming from an evill.com It says refuse to load the script and this is how you avoided the content security policy So I can give a quick demo where we have a given this one ability and it could be I would just So I would just quickly set the header as csp I'm sorry, but I'm not able to put that in the screen demos are hard anyway, so The screen is flickering I would actually have the header set by myself and If we try to load this expressions It was working five minutes ago, but anyways So going forward we can talk about mitigating xsx and Let's talk about some common mistakes where default source will be used as a fallback and You actually have to you know void using wildcard domains and Default source would be omitted If you do not specify it and it's it's not very advisable to do that and use of dangerous elements like unsafe and line unsafe eval and also wide listing domain with jsonp endpoints user uploads or Open tree directs are dangerous And if you want to break some stuff get a back specifically in wise researcher to break their CSP policy and Hacker one has also paid have some paid bounty CSP bypass and The draw box is also having CSP journey blog where you where they have published some interesting articles about how they have Migrated their journey from having a CSP not having CSP to having CSP Now that we have understood how CSP works and now it's how how should we deploy? CSP to our production and there are two ways where you can actually The first one can be used to block and report attacks There's enforcing it and the second one is the report only where you can allow the report report abuses to a specific reporting server and When we when I say about the reporting you can actually have the policy with the headers and condensic already policy report only and you have to specify a reporting URL where the logs would be sent to and for this you can use report uri.com which could be very easy to maintain and get a get a complete idea about these logs and Now let's move on to Interesting approach where you can use CSP to migrate to STTPS and Life is about to go harder for the website having non STTPS and Chrome is actually going to mark all the web non STTPS website as Non-secure starting July 2018 and CB migration is very hard for legacy applications where you know you have to Do a lot lot of code-based refactoring and and Thus you see you cannot specify a directive Called default source and which is set to STTPS and a form action which says to STTPS Which you're using which you can identify what all assets are loading using STTPS and Also, it helps you in secure identifying where the secure form submission is not happening So when someone try to load an image using STTPS it would also violate the policy and There is something of there's a source. There's a directive called upgrade insure secure request which would basically Upgrade all your STTPS request to STTPS and for example You have an image which is loaded on STTPS Before sending the request to the server the browser would convert that request into STTPS and Thus doing all of your work without specifying these Specifics changing the schemas in your code base and you just need to apply this particular directive in your condensed security policy and this can be combined with our other fetched directives and And so Next one every I would want to talk about click jacking Everyone thinks that it's a solved problem Where you know, it's this one everybody basically is a malicious technique where you can trick a user into clicking Into a something different what user sees that and if user is able to click on that He would be actually compromising some confidential information or even It could lead to account takeover basically it looks like this where you be you're trying to click on a button and It it gives you something different. I have a demo for this See how it works So I have an application so which has a feature called delete sensitive information and with GDPR coming alone Along you must be developing this particular feature for each and every applications and when you have such critical User-actions and I try to so we have an application running on host 3000 and I have another application running on 3002 so The this these two application do not rely on the same origin and user would not be able to Share any of the resources now if you see this particular website where I have set the opacity as very very low and You can basically see the iframe this and when you try to click on this button to see awesome dog lips and you are actually clicking on something different and and Here if you are able to see that there's a pop-up coming on that the data has been deleted and So using this particular approach where people are Hiding some informations on their browsers behind an iframe user are actually making people think that clicking on something else and But we have seen that these vulnerabilities can be Easily solved using header called x-frame options, but with this is with the support like deny which will not There's a parameter where you can define deny which will not allow the website to be iframe and Then you have same origin which could allow only this the same origin website To iframe the website and then you have something called allow from which is not supported by IE and Chrome and Which allows you to define a URI which where you want to allow the iframe to be Loaded and but interestingly we have these two approaches where same origin and allow from works Very differently where the expected behavior would be to check the domains the ancestor domain and Actually, they are checking the top level domain to the current domain. So to have it understanding the better way Where someone is able to inject iframe inside a page we just loaded on victim.com and They have inserted another frame. It's like an inception Where you are loading in tacker.com and inside you are loading in victim.com now The browser would check the top domain and the current domain and instead they should have checked You know very in sister path and which is not being supported by x-frame option, which is kind of wrong So how is it a problem? Where you have the site that frame untrusted pages? That would be wonderful And while I was creating slides for con insecurity policy, I was using slides.com and When I tried to load the response error and I can see X-frame options are same origin policy same origin attribute and if it's there, I am able to add HTML where I was able to add the iframe and And it was wonderful. I reported the wonderfully and I got a free upgrade. Yeah So how do we pretend prevent a clickjacking using CSP? There is a directive called frame and sisters where you can Define as none that it would not allow any website to iframe it and Similarly, we can specify multiple domains along with self. That means same origin and Similarly we have Other approaches using which you can prevent a type of attack where you can combine both x-frame options and CSP where you know the CSP is supported by a maturity of new browsers and old browsers like below Chrome 30 would not basically support some of the directives. So you can apply both the approaches and draws will take care of it So CSP is kind of cool You can do a lot of stuff. Do not break stuff. I have another demo in place where I Would not open my editor again, but no break. I have an exploit which I can copy and Put that inside So there was the xsx which we have seen on this particular page now you can see that There was an exploit which I have copied and I have shared the URL with them, but what actually happening at the back? I opened my developer console. I was actually running a crypto Mining that's crypto checking which I have been talking about at Prince's beginning and I have been running and Generating some good gold crypto mining and the basically Where I was able to collect all these hashes and if you visit this particular and if you try to run this particular applications on your browser You would actually be helping me giving some money That's how you can respond to my talk So yeah, CSP was cool if you want to deploy it do not break the production you can use content security report only header and You can if you want to learn more you can have a reference guide Which is on content security policy comm follow this guy Scott and actually he was the one who was able to identify all this website got infected with triple jacking last week and Helping with the website government website as well and he knows His stuff he knows about CSP and also you have a useful scripts on this particular URL and I'm also going to publish some Handbook which I was actually working on so that's all I got for the today's talk Thank you very much, and you can follow if you have any questions. I'll be right about right here and If you can follow me on kid up or Twitter if you have any questions answers yeah questions My I start one with a question. Yeah PWAs progressive web apps they require their base on HTTPS. How far do I really need then? content security policy So all these applications where you have to define actually Content security policy and going forward these would be mandatory by the browser and it's basically even if you I have Honestly, I've never worked with PWA, but I would actually say that if PWR going moving towards secure context There is a CTPS and they would make sure that CSP is also being followed by them