XSS mitigation: the state of the art

welcome uh for the last talk of of the day probably for most of you uh crossout scripting mitigation state of the art i would like to apologize for two things first we're french so if the accent does not go well with you sorry feel free to ask us we will repeat uh and and the next thing is that so we have tickets for top gun tonight but that's not the the schedule of the sessions sorry about that so i'm jb i'm a staff engineer at datadog i came here with the screen acquisition i was a cto and co-founder there so i've been working in application security for a long time and i'm vlad i'm also a staff engineer

at datalog and i joined screen a long time ago to enjoy datadog through the acquisition feel free to follow us on twitter we'll share the slide there uh later tonight or tomorrow speaking of the slide here is the topic of tonight we'll start with some xss refreshers just to make sure that everyone is up to date on the attack then jb will describe the attacker point of view because he's a seasoned hacker and he will do a live demo of xss exploitation then i will be talking about browser and server side mitigation and there will be another live demo meaning that we have twice the chance of having things going wrong during the talk um and at the end

of the day jb will summarize its inner parts named xss threat models all the links in the presentation are available at that qrear code but don't worry this qr code will be also on our last slide so what is xss that stands for cross-site scripting right i'm sure you all know what this is basically when you have user input somewhere and you can enter javascript or html in there and it results in something like that have you all seen that i'm sure you did who already exploited the cross-site scripting here all right okay okay okay so no no not not beginners that's a hacker audience so uh let's recap what are the main cross-scripting variants right so first

you have the vector it can be either stored or reflective those are the most common vectors studies in a database in the local storage maybe in the cookie sometimes and reflected it requires the user to do something so that the payload gets gets triggered right and then you have the injection the injection is where the actual vulnerability lies so it might be in your react application it might be on your server side uh code rendering and last but not least you've got the universal xss here it's usually uh sitting in the browser it might be in parts of the operating system but something that is independent from the from the website so those are the main

uh categories so back in the in the old days of the web like 1995 um jarvis the the the web was mostly like php or a vast majority of the web was php and you had like very little templating engines and the ways you could uh exploit yourself scripting was pretty straightforward in 1999 the term cross-site scripting was coined by microsoft and and the film didn't get a lot of uh hype at the beginning it was a bit like neglected by security researchers or something not too important and to be fair um the web was not as full as sensitive functions or information as it is today but still it took a long time and and

you can still feel it from some old school security researchers that are crosstalk shooting can be neglected thou despite being like uh 20 years old or so in 2022 you still find cross-site scriptings in react applications uh it's still part of the wasp top 10 it's part of the top 10 most discovered vulnerabilities and bug bounties according to hacker one and i think if you work in a company of any decent size that's something you you know about yes the web security model is something that is as old as the cross-site scripting because it was introduced by netscape in 1995 along with the first versions of javascript so basically that's helping describe how browsers should

behave uh when uh it comes to handling several origins so you have iframes you have network communications you have several resources that get through gathered by a web browser and the way the browser should behave from a security standpoint where should it send the cookie what should it allow to read where should it follow the requests all of those kind of things are rejected by the same origin policy sop in short obviously all brothers have dispregnancy etc this thing from 1995 is still key to the way the the security model of the web works today and that great resource the um tangled web is is amazing if you want to refresh and start with the basic of of

the web and all the fundamentals of the of the web security so cross-site scripting is a vulnerability right that allows an attacker to run javascript within a user web page or something that's good but so what do we do with it a lot of outcomes are possible with crowd size scripting and those are only a few i'm sure i'm missing a lot and depending on the context you can find a lot of other things so for instance you could steal the session in some cases still the cookies still the authentication headers you can achieve persistency with like modern workers in a in the brothers you could do network private which is very fun thing to do

if if you put that with a botnet meaning that you compromised a lot of users then you can achieve a distributed denial of service and one of the most important thing that you can do is the action hijacking so basically if you have a crosstalk scripting within a website well your code as an attacker is running with the same contact as all the other code of that website and you can do any action so if it's on facebook you could add people you could have friends you could post messages uh probably you could wait that an admin is uh is seeing that page in in running action as an enemy so a lot of things can be achieved and we can think

of course as scripting as remote code execution for the web it's like the somehow almost the ultimate vulnerability if you if you have a website the ultimate vulnerability that can target your users so so let's see the attacker's point of view um that's uh a ratter that was uh used a few years ago in mostly eastern europe and some malware manage using javascript to reconfigure this router and what did it do it injected custom dns name servers so every user of that router that triggered that malicious javascript payload got to use custom dns configuration and those custom dns were redirecting some specific banking uh domains and the the attackers behind it stole the credential of a lot

of uh of those users so that's one example of something that you can do with uh with a cross-site scripting you can private change the network access other things that would be on localised here obviously attackers were using known credentials that the isp were using for that routers and default ip addresses that were working in most cases that's a list of exploits that have made cross-site scripting famous so you still have a lot today you can see a lot of them are being added every day on some major websites but if you look at bounty programs for instance crosstalk shifting is still something that companies put very high in that is despite that being a 20 years old

vulnerability um and the most famous one probably from 2005 i'm not sure we had any with a with a similar or as spectacular outcome that was the same one who added a lot alter like one million myspace profiles so that's basic web security right so didn't change much in the way you you exploit your subscripting but you can think of other targets right browser extensions and and one big thing is electron apps that are also using web contacts and here of course i scripting might be an actual remote code execution where a cross-site scripting can really lead the attacker into running actual code on uh the the victim's machine all right so no need for

in some configuration no need for fancy browser exploit or sandbox escape sometimes you you have direct code execution obviously electrons become much more safer in the past years to to prevent those kind of things but that's still something that you find and obviously you have some common bypasses one of the most recent and interesting ones are the script gadgets so uh they are assuming that you found the cross-site scripting exploiter exploit somewhere but that some protections are preventing the hackers to to exploit it script gadgets will leverage code from the frameworks to actually inject something that will get executed by the framework which obviously is authorized and will actually reach a javascript execution and content security policy that vlad

will describe a bit later is also something that can be bypassed it's complex it's hard to get perfectly right and pretty often you can find bypasses within content security policy so you have tools that will test them for for weaknesses and the the content security policy evolved lately into something much more flexible using strict dynamic et cetera it was very very hard to implement a few years ago and it's becoming more and more realistic to uh to implement so demo time so let's assume that uh i'm a hero hacker right so that that black window uh is my uh my my hacker window right so this is beef beef is an exploitation framework so as an attacker i might be

using beef in order to uh collect some crosses scripting payloads that i've put on many websites right so what i will run as a javascript payload is not a script alert to demonstrate that it works it's a url pointing to beef my beef instance for instance and that thing will allow me to do a lot of things on on that cross-site scripting so let's assume that i'm the administrator of a blog that blog is running ghost and i'm visiting the the website just to to check if everything is fine and here we have a page that is vulnerable to cross-site scripting and that has been injected by the attacker previously alright so as an admin obviously i don't know

the attacker would not label the page as xs as vulnerable hopefully and so when the attacker looks at their console they can see that we have that browser who showed up all right so what can we do with that you have a lot of information about the browser that's pretty interesting and you have comments so comments are actual javascript payloads that beef can instruct the victim's browser to execute and so you can think of anything you have like a metasploit integration to exploit like zero days and some browsers or whatever and here in that case i wrote a very simple payload that allows to add a user in the in the website so i will just put like

uh some some email so that's my actual email and i will execute the payload okay after just a while we can see that the the payload was fulfilled and if as as a staff i come back in the in the console i can see that yes the uh the user was was added so all i did was actually run javascript in describes that scripting session with the permission of the user who is a blog administrator and so that allowed me to do that all right that's a typical cross-site scripting exploitation use case where you are leveraging the actions that are available to regular users of the website but silently

vlad my demo didn't break so okay no pressure on me um thanks jb so now normally the next question is how can we protect against excesses and the question is multiple way exists to protect against excesses so let's start with what happens browser site small disclaimer sometimes mechanism in the browser necessity mechanism server side so maybe the separation which may we made is a bit arbitrary let's just go with it so first solution no javascript no problem right so um disabled javascript might be please don't do that might be a solution to disable xss one of the pros basically no xss cons well you need to ask your own user to remove javascript from their own browser which

is challenging on modern browsers and also that will remove access to the world modern web so sorry for french i did not manage to get this error message in english but there's basically a twitter yelling at me for not having javascript enabled funnily enough in 1999 when javascript and the threat model of the web was not that mature there was a cv published impacting netscape navigator and internet explorer why they would say that javascript could be used to track users over the internet as the time have changed so anyway please don't disable javascript and don't encourage anyone to disable javascript this was totally a jukey slide content security policy so content security policy jb already a bit touch

based on that basically that's a header that you add to the website where you serve it and you define where the assets used by the html documents can be loaded from for instance you can say that the scripts can only be loaded from a certain set of domains or that the images can only be loaded from the current domain and you can even put hash integrity hash to make sure that script images style sheets are not tampered with that's actually pretty powerful there is something extremely cool with csp and not csp policy because it would mean content security policy pc and that would be slightly redundant so this thing with csp policy this thing with csp is that

you can monitor them so when there are violation the browser will send actually a post request to a server that you defined in your csp and you can monitor that you can also configure your csp to be non-blocking or blocking i will come back to that in a minute so csp is easy to monitor but that requires a lot of traffic going your way so there are a few sas that can be used to monitor csp in the wild and let you know in real time uh when your csp is your when your policy is actually being breached which could mean two things you're under attack and someone found an xss or your website your website is broken because

your csp is not up to date shameless plugin datadog can help you monitor your csp that's the only piece of advertising in this talk sorry about that um csp might be hard to maintain because you have to update it each time you update your assets in your website let's say you want to have a new dependency from a cdn well you need to make sure you update your c you update your csp otherwise this assets image script anything will be blocked and your website will be broken thankfully thanks to monitoring you will know that faster than your customer will complain but it is not supported by very older browser as most of what we will discuss

today anyway so feel free to check that out that's a really cool piece of technology but can we go even further than csp yes we can introducing trusted types trusted types is probably my favorite xss make a defense mechanism mostly because i'm a javascript node but basically you have a csp and you define what's called a trusted type policy in it so you say hey i will create a javascript piece of code that i will name sanitizing policy and each time you call in javascript what are called the things well it must go through a sanitization method before that so let me start again trustee type consider that there are like three things for xss

create html when you call inner or auto html on a dom element create script when you call eval for instance or create script url when you load dynamically a script from another piece of script when you enable trusted types you create what's called a policy which is just a set of javascript function and when you call inner html for instance if you call in html with a string that is not the outcome of a sanitizing function this will refuse to execute we will demo that in a couple slides but the idea is that you cannot use these things without going through the policy before i go to the live demo and have a chance to do something wrong live

uh let's talk quickly about dom purified and purify is actually a library it's pretty mature it's an open source project and basically what it does it sanitize inputs so they can be used safely rendered in the browser in the dom so it's really lightweight and it plays really well with trusted type but as any of these kinds of libraries it can have false negatives or false positives so one must be really aware of the behavior of don't purify when they use it also since it's an open source library everything is public and you can find order bypass bypasses in the previous version of it just by looking at the changelog the really cool thing is that dom purify

is actually under the process of becoming a web standard under the name of html sanitizer api which is currently supported by xero browser last time we checked uh but that's an exciting part because uh the web is currently building more and more tools to fight xss from your code base dynamically okay that's the part of the top where i'm terrified so let's go for the more time in this demo we will just play with the same website let me zoom in a bit because on keyboard yeah so that's a website it says hello i was too lazy to write world so let's make it a hello world website now username equal world and now it says hello world oh basically

thanks baby that's basically a website that you can use to greet anyone and you give them the url and say click on that and they are greeted by that the hackers the hackers here recognized reflected down based excesses and that you can throw forward to people through um through social engineering so let's explore that should we as you can see it has been programmed by someone who doesn't know much about the web so if i do emg dot src equals x which is an invalid url i even put a z here and we can put an error call back on air roar equals alerts and let's try that and here we have we are running arbitrary code and we can

send that to people steal their credential and their bank account money and pretty much impersonate them because we steal their identity which is terrible so let's fight against it to fight against it we will first try to enable a csp so if we check the code of my web page you can see that i'm a very good web developer i'm still using align center because i didn't want to put css in that we can inject a csp directly into the html page we don't really need headers the the web is related so let's say we want images to be only loaded from the same domain in theory that should prevent loading this arbitrary image right

let's try that okay so good thing it's already there we still have an xss why because actually the xss is not unloading the image it's unloading the arbitrary scripts that happens when we can't load the image so if i check the console inspect that's not my laptop and jb as a french keyboard that's why it might be lost if we check the console it tells us refuse to load image because it violates the content security policy so it doesn't want to load the image but the script is not part of the image so it's a valid thing so what we need to do is actually prevent loading scripts from arbitrary places so i've updated the csp

and now i've got content script ssc and then i put unknowns yes you can either use hashes domains or nonsees to define what a set can be loaded so in that case i just generated a random uid and in the script that runs the code i've got this as a note so basically this csp means the only javascript that's allowed to run on this page is that one and none of those okay so let's check that in real time i still have my exploit in the url refreshing and we don't have the easy access we save the web okay it would be too easy if we didn't use trusted types and because i met at a

security conference i want to show some real javascript code because i'm a javascript nerd i think i mentioned that already we know come on i made all my carrier with no.js don't be mean so you know what let's add a trusted type let's say that we want to be better than that and to have dynamic so i still have a csp no policy and i say trusted type mypolicy and i also say require trustee type for script to make sure it knows it's not allowed to run scripts without trustee type okay so i told you that the policy needs to be defined and thankfully there's actually an api available directly in the browser so we do

trustedtype.createpolicy we give it a name so i named it mypolicy like my first dog and uh in this policy creation you create something for the things so i told you there are three things things one for html one for js one for js for url this one is for create html so that's a function that takes a scree a string as argument and returns a string okay that's an easy function it does not sanitize much but let's see if it works let's try that so it's step three oh my god spoiler alert i refresh and here i write username equal world and nothing happens why because i forgot to sanitize my content before passing it to inner html let me

show you the error in the console encode type error filed to set the inner html property and element these documents require trusted html assignment why because here i'm assigning to inner html without going through the sanitizing function that i have defined in my policy so let's do that properly we have exactly the same code but here we call window.mypolicy.create.html and now this outcome of this function is actually load to be used for inner html assignment okay so let's go to the next part let's refresh and we still have an xss why of course because my son is my sanitization method was not sanitizing anything right if if we check the sanitization method here it actually returns the argument so it's

not sanitizing anything we are missing the last bit of the part so let's go to step five oh my god it's been written so well and here we are calling dom purify which actually sanitize the input so let's go to the step 5 refresh the page with world as an argument sold yeah that was my first nickname on the internet uh and voila it works because this thing is not actually a malicious payload and if i go back because i'm too afraid of typing a typo i refresh here you have my exploit and it doesn't do anything because it has been sanitized by dom purify configured in very strict mode so so far so good we did 2d move over to jb

can i get a high five please so i'm gonna give it to you but uh you know in security conference yeah yeah and you just give the entire audience the name of your first dog oh yes so let's talk a bit about the cookie thing because jb and i have an obsession with cookies uh i mean the treat not the um but okay so it's actually really important to consider cookie when you are considering the web freight model all together you should use ht you must use http only so your cookies are not available through javascript disclaimers that won't prevent people from impersonating your users through xss but that will prevent people from taking these cookies

and taking them somewhere else like escaping stealing those cookies so they can still use them in the scope of the venerable website but they cannot take the cookies outside for the other parts they are not that much linked to xss but any slide about cookies should talk about all these attributes so let's go really quickly over them secure the cookies can only be exchanged over https no unencrypted traffic domain path and same seat we know exactly on which hosts those cookies are sent to so this prevent cookie theft this does not prevent escalation please do that that's really like web security 101 and in that just follow my quest who who is a guru of the and on the google team

all together uh exceptional in terms of evangelism around excesses and cookies and and also in terms of writing the next generation of web protections google but also like mozilla the the those browser teams are really pushing forward and and that's very often thanks to them that uh safari for instance is catching up after he's catching up on the under the security measures um so just a word on the on the future of browser defenses we we talked about what's available today or mostly available today um content security policy continues to to evolve uh the most common uh kind of evolutions on it is uh it's following the brothers revolution you know with uh walker scripts with uh wasm and all of the

things are are able to be expressed in a in a policy so so you can restrict them accordingly so the html sanitizer api that vlad described you know it's very hard to write parsers and so it's very very hard to write two parsers that will behave in the exact same way so each browser is different so when you are using them purified it's sometimes difficult to ensure that you have the same level of protection across all brothers you can often exploit like mismatches between the the dumps and the dome purify parsing mechanism and a specific browser passing mechanism and the the html sanitizer api will make it built into each browser so the the parsing engine of each browser will be

used which should supposedly make it much stronger and if like a common way to to bypass don't purify is just to look at the fixes on github and you will see often fixes for um for incoherences and and supposedly if the parsing mechanism is the same as the web browser that should not happen anymore another hard thing is a spectre and side channel attacks protections so you you know the the principle spectre allows leaking any piece of data from a given process so that's that's a very powerful attack but if we consider that from the web point of view that makes it very hard because as a developer you need to understand the security model of the browser and you

need to know whether an iframe is loaded in the same process whether a subdomain is loaded in the in the same process or not and all of that makes it very very hard and for web developers to cope with the implementation of each browser obviously um so the the the web browser vendors are currently improving the way they protect against that google is very active on that front they shared some exploits that can run and and they have exploits for most browsers and on most platforms it's not only internal it works on m1 etc um so uh that's that's the real thing and uh the way you can defend against it is pretty complex you have a

fair part of new security headers that are restricting what browser can do from one another and if you are using stuff such as a shared array or buffer then it's you you need you will get error consoles if you didn't set the proper headers in the in the most recent chrome conversions private network access is also a security measure that will prevent the kind of attacks where we've seen attackers pirating on your internal network to talk to your internet box for instance a document domain is being deprecated and last but not least the credential management is also being proposed currently um the good thing is that that will make a browser-specific mechanism to handle uh

login and drag out and that hopefully will remove the ability for malicious payloads to spy on the keystrokes vlad thanks and now we got you with a fancy modern way of protecting against xss in the browser because the browser is the future let's go to the boring old server side stuff okay so xss server side they happen when you render html right when you have unsafe stuff rendered into the html which is just a string document you share over the internet to the real world well the question of how this document is rendered how this string is constructed actually has an impact on your attacks your face so let's talk about things from when jb was

was was younger php i was still in i was still in primary school about programming with sea battalion web programming with php and back then you still now but probably less than now you just do php eco with a variable and that's just like a string replacement you know it doesn't care about what it is rendering where why it's replace strings and that's pretty much it so here the templating engine does not have any context about what is actually doing it's just building strings that's why you have high risk because the tooling can't help you it doesn't know enough to help you or whether if you get too modern or stuff like erb egs well

it's context agnostic but it still knows that it is rendering something that should be escaped so full full disclosure i'm not really a big fan of this syntax because escaping is just made by using an equal after the percent and not escaping is using your dash and i find that like really really really error prone that's not explicit enough in my opinion but anyway what happens here is that it will escape the content of the username variable html escape to make sure that it is not rendering html tags and on the last one that's such a great animation jb and on the last one here we are using directly another language that has nothing to do with html so it has a

lot of context on what it is rendering and it can know what it is doing and reduce the risk surface we will see in a couple slides what is the future because it's definitely doing something with javascript directly um okay i'm not sure why we had this animation here okay so also i told you that csp where it was hard to maintain because you have to update them continuously well just tune your server side stuff to help you there for instance here we can ask the the templating engine to generate announces for the script meaning that nobody will be able to inject a new script because you told the engine i'm generating a script tag so it

will uh generate a nonsense for this one but if you generate rogue script ones they won't be added to the csp however that won't help you if the script tag itself contains part of code that can be injected like if you let people dynamically write javascript triables in the scripture render you're probably doomed for eternity in my opinion but that won't protect you against that that's not a silver bullet and templating engine as i said are getting smarter and smarter so i will talk about react for for a slide react is actually fascinating because it's isomorphic javascript meaning it works in the browser and server side and it has different ways of mitigating xss depending on when it's training in the

browser or server side in the browser it will be using safe apis uh it will be using document element.text content instead of html there's actually a method in react that's called set dangerously set in your html and probably there's a comment around it do not choose it but it has dangerously in the name so the only way you can shoot yourself into a gun while using react is by calling a method that is that has a name that dooms you for eternity but on the server side how does react do well react actually is aware of what it's doing because components are defined in jsx so on line five here we've got a gsx component and react is aware of what it

should be rendered and what should not be it's like the next generation of that so here i'm rendering it server side and react has actually comprehensive uh xss filtration mechanism the only bypass we found is using javascript colon in links and stuff and actually when you do that server side there is a warning message saying oh that's working right now but in the next version this will be duplicated because that's actually unsafe so the only bypass i found they were already aware of that and they are fixing its exertion that's a brilliant library and that's amazing and that's javascript so it's amazing okay let's go deeper in the traditional mechanisms i would say to be

polite static application security testing that means that you have a program that will just read your code and find vulnerable points they have been amazing talk earlier today on that exact topic and that's a very strong uh that's a very strong technology they have been made they have made a lot of progress on that front and that worked really well when you have a pro properly typed programming language so in java static analysis is extremely powerful in javascript well javascript is a real language so it is so polymorphic that static analysis can be extremely complicated but this is an important tool that you can use and there are like a lot of vendors or free or free tools

to do fast nowadays and that's probably my favorite slide not only because it's three hours old uh but that's if you want to take a picture take this one yeah because it's it's incomplete but it gives you an idea of what you are doing depending on the protection you are using you are actually mitigating a given risk and there is no silver bullet to fight xss this is like a teamwork between all the mechanisms that are available in the web but i don't want to spoil the next part and yeah just on the on the previous one you could visualize it in 3d and imagine the browser supports right yes thank you plan you could visualize it in 3d and

including the browser supports would make it extremely complex that's really not simple but yes and you can notice the star on the first line which is all the new cross-origin things that have been added recently uh and and that make it a very unstraightforward just to say the list so on server-side mitigation what is what is coming next there still are a fair part of the of the web and they will still be right you can use react server side or brother side uh ruby on rides is not ready to go away java and gsp and everything so um we have some solutions uh at development time obviously you you could pick a templating engine that will automate csp

generation uh you already have similar things in in webpack in regs and django for instance in rails using secure headers uh with a well defined templating engine that would automate most of the work for you and then you have some security products um so something that i'm not really aware of the but that should come and all the new browser apis are making it much easier to implement uh you could have dumb exercise protection uh in the runtime in the browser so that that will really help also could work in in detecting vulnerabilities and the second part is will be led by apm vendors so since apm vendors have access to all the context of the application something

they can do is actually instrument themselves the templating engine and dynamically inject nuns and build the content security policy accordingly and so those things will will probably arose in the next in the next few years so we talked about everything that was like right so now let's shift left and think about the the design and the threat model so shifting left means you want to be in full cooperation with with developers and just ask them the last questions right so in in a very nice way not at all in a in a scary way so don't don't do exactly that let's rather um use those kind of uh topics uh that should help you get a

fair understanding of how the application is working and what part as a security team you should focus on so for instance html generation um okay how is it done is it static is it dynamic are using cross-site communications with other iframes or other domains maybe what about the clients um is the app or the service talking to the browser to another service is it only a generating json is it an api of course the inputs where are they coming from is that the network the data stores the user and of course there is the business level so is the application doing authorization authentication of the users are the users admin support or regular users all of that has

very depending privileges and of course is the app using sensitive business functions like deletion permission management adding administrators as we've seen in the in the demo and uh in each like um threat model that you can do with the developers you you it's sometimes not easy to ask the right question it might and like that so don't do this either please so depending on the frameworks that you are using the risk will be very different so that's also something you need to pay attention to as a as a security team so in the case of uh server side rendering well the vulnerabilities might be server side and also sell and also client side because uh

you will be using i don't know like jquery or vue.js or rails fancy uh stuff that will make it potentially complex to to edit in the case of a single page application well it might be much easier to audit because all the inputs are coming from the network and so you can really rely on the on the application if you are using trusted tiles on top of that that will makes the auditing much easier so it's the simplest to edit i would not say it's simple down and of course we have the hybrid version of it where here you can have vulnerabilities everywhere and that really makes it the much uh harder to uh to uh to audit uh to reason

about as a developer or as a security engineer obviously supply chain security is also a big part of the of the game and so all the remote dependencies that are included by a web application can be tempered with you could have cash presenting attacks the hosting can get compromised and non http fetching because like attackers could man in the middle the dependencies and so you have some partial solutions using for instance subresource integrity sri that will allow you to add the hash of a dependency within the the script tags that are requiring it that can be automated using for instance webpack another option would be to bundle locally in that case obviously it's not magic because if the hosting has been

compromised before you you fetch it yourself then you will still be screwed so now let's let's take a step back and resume what we what we have seen during this this presentation so we have defense in depth when even is introduced obviously you can use modern frameworks flight models static application security during the runtime to prevent vulnerability exploitation then content security policy mechanisms rasp and apm like mitigations and last but not least to prevent the attacker's outcome you have a lot of other things like all the headers that we've seen cookies attributes browser hardening and down to bug bounces and pen tests that's it folks thanks for your time today [Applause] if you have any questions happy to

return and take it we don't see much with the withdrawal yeah no question no question i'm good i want to see the drawing one question oh one question

so the question was are there differences between an inline security content security policy and one that has been set through headers from the server i think from the browser's perspective not yeah so you can content security policy you can use rebuttally mechanism to not apply the the policy but just learn from it so you get the violation reports when something goes wrong and that you cannot use in the browser so that's one thing and then it's it's useful for testing but from an enforcement perspective you could imagine that the the the page has access somewhere where the the the policy is prevented from being injected so you the the the specifications say don't do that

you can use it for testing that's mostly for testing and demo purposes amazing thanks so much enjoy the rest of the weekend and thanks for coming to our talk thanks [Applause]