XSS is dead – Browser Security Features that Eliminate Bug Classes

Welcome to my session on eliminating bug classes using browser security features. Um yeah, I hope uh you are as excited as I am about this topic. Um the the purpose of this t talk is for you to get new ideas, new maybe learn about new concept that you have not seen before. Um and uh maybe you can think about how you can apply them in your own workspace as especially the the the scale deploying such browser security features across a big landscape of applications about multiple products that you own or uh multiple servers and yeah let's uh kick this off. So um we are going to talk about common web security flaws. I will show you the

latest version of the UVAS proactive controls. Um I will show you a case study from Google which was like the um the the yeah my I I found this when I saw this research paper from them about security signals or web signals. uh I was so impressed that I wanted to bring this to my own organization and also apply this concept and that's why I want to show you their concept how they implemented this and uh then finally we will talk about uh some of those new modern browser security features uh for defense and deaf and um like I said um I was um so there's also um uh I also have a 4-hour workshop version of this so it's now

very difficult ult to put everything into a 10 20 minute presentation but but I tried and I hope you're going to like it. Um but of course there's uh much to consider especially rolling it out on on a scale and and so on. Um and um yeah the the why are we having this talk is mainly because uh I thought um those topics they haven't surfaced that much yet um like uh moving to a strict content security policy but also other very modern browser security features which are still in development and also not yet supported by all major browsers. But it's very nice to have a look at this development and think about how you

can already deploy them um because they already provide very great value and um yeah I wanted to bring more attention to those type of features and um generally moving from having this reactive mindset to this proactive uh mindset. So uh a few words about myself. So um my name is Yavan. I'm based in Germany. Um I work in the application security team at Sage. Uh on the side I'm lecturing secure coding. Uh I'm passionate about web security, Raspberry Pi stuff and home automation. Um I used to used to do software development, web and mobile. Then I uh became a pentester and a consulting uh type of role and now uh I'm uh like I joined Sage 5 years ago in

an application security um team and uh now I'm focusing again in in scaling and building stuff again. Um so there was some change in our mindset how we approach application security as well. Um so before we start let's take a look at the common web security flaws that we have. I took here that I mean there are there are many top 10 list that you can use but let's take one top 10 which is the hacker one um top 10 vulnerabilities of the most reported and most rewarded vulnerabilities in their plat platform. And you can see number one is still cross-ite scripting vulnerabilities. This is uh yeah a little bit insane because it's a very old depend uh

vulnerability. Yeah. And we we still don't really manage to fix it um properly and um it still surfaces and and I also cycle some other type of vulnerabilities uh which are also covered in with some of the controls that we are looking at and um during this this talk. So um yeah um maybe maybe um let's take a look why is cross-ite scripting still one of the most rewarded or found vulnerabilities um so many organization I think first many organizations still struggle to implement a strict content security policy a strict one um but also having challenging to find all vulnerable spots for where they can do input validation and output encoding and so on and Uh

second attackers still find very innovative ways to bypass those um defenses and this for me this is a a proof of or uh that we need those layer defenses multiple defenses and we will look at those and look at those browser security features which we can use. So even that you even if you forgot to do a proper output encoding that you still have like a content security policy a strict one which then blocks that cross-ite scripting attack. Um so why do those vulnerabilities still persist and let's let's um before we move on so first we have very complex systems um um lots of connected APIs many uh application I think I don't know do I need to just continue

talking and then it's not okay that's good so uh second um we we have a very reactive mindset about u our vulnerabilities um like we We we fix uh occurrences like a new issue that pops in from a back bounty report or from a pentest report and we only patch those symptoms. Um and we have a maybe third we have a limited automation. Um so it's hard to scale those security practice across a landscape of many applications or services. So um I compare this like this a mole game that we are playing. So we have this constant emergence of new issues. We are very reactive not proactive and with that we have a never- ending cycle and it became very

stressful resource intensive and with that of course we don't have time to properly look at the root causes and also no time to implement those proactive controls. So um yeah then um I wanted to show you the the last version of the overas proactive controls which is a top 10 list of very good practices and of course number one number two it's all about input validation output encoding does those usual practices that we already know and that we already apply uh every time we have a vulnerability coming in in a pentest report or from any type of static source tool scanner. So um but I wanted to show you the number eight which got added in uh the last version last year

number eight which is about leverage browser security features. So we now see there's indeed something happening uh which we should take a deeper look during this talk and um for me this also means um we we need a defense and death and this is basically how we scale the vulnerability elimination because we won't be able to patch or all the input validation or output encoding maybe we maybe we won't be able and that's why they still surface is so we need this defense in defaf and here are just a few examples how you start doing that uh like the first one here session hardening you add a HTTP only flag to your cookie so that

a JavaScript if you have a cross script vulnerability cannot access that token or that a that key from the cookie so there are multiple different mechanisms um and the last one finally is browser enforced policy is about having a a secure a strict content security policy just an example for some of those defense and death mechanisms. Now I wanted to show you the that research I was talking about initially from from Google and uh you should really re look that up and download this paper and read it. It's very very good. um it's called security signal and uh but I'm going to show you how what it actually what they actually did in this paper because I I use it as a blueprint

as a template to now work similar as they approached it and in my I mean it's from Google uh they they kind of own Chrome and they they worked on those standards they worked on this content security policy version three they worked on those new security headers which we will talk about like sec fetch metadata and some other sec security headers does. So it's of course they also have now a very nice approach of uh not only adopting it as a certain scale but also measuring the adoption at a certain scale and that was what I found interesting if you work in a large enterprise. So um let's take a look um at a challenge. The challenge is of

course adopting to those uh security features in a very large scale web ecosystem. And uh what they how they appro approach this the solution is quite easy because most times you anyway already have a reverse proxy like an engineix in front of everything or even if you use a commercial version like cloudflare you can you basically already have your man in the middle you can inspect there and you can put up some truths uh some rules uh first not only setting those security headers but also um yeah uh checking if they are existent and then you can apply that as in one says for everything basically and that's basically where where this works. So it's like a proxy level and uh they they

use some um synthetic sickness that's how they call it. So it's about making it measurable. So actually they check on each um service they check for example is their content security policy existent is their CSRF uh protection existent they check are they security fetch metadata header existent and we will I will talk about those and explain how they work a little bit later. uh but also also of course interesting do do I have a a legacy application do I have a modern framework maybe the modern framework is already doing the output encoding by default so like it's giving us very good indications which we could inspect on a proxy level and finally so this is screenshot from that paper but I

found it very useful uh to show you how you can make it measurable like like a this is a scorecard which you would have for every service and uh here they show you okay we have a trusted type uh header set we have um some other headers um defined and this is just the outcome um of that of of those metrics um yeah u unfortunately there's no commercial product this is not open source we have to build this ourself right now so vendors please listen but uh um it's a very good innovative idea um so um let's talk about those browser security features which I just mentioned uh during those slides. Um uh but before

I uh talk about those I wanted to show you a cross-sight reaches forgery vulnerability. Um for those who don't know it's like imagine you are browsing the web and uh suddenly there's a request made on another website that you also already logged in and then action is performed and you can see that image tag. This is then a example how something like that happens because browsers tend to send cookies automatically with each request if you don't have settings like same side attribute set to those cookies. So this is a attack can look like uh this code snippet as well. But now there's something new which um is those security fetch metadata headers. And um with

those headers um uh they they got introduced in 2021 to all major browsers. So you can start using them. It's another defense in def how you can protect about cross-ite retest for attacks because now you can start validating server side on or on your engine proxy level where did this request came from. To make this more clear, this example, this is how a curl request looks like if you send it in your command to example.com. You just have those this bunch of headers being added to the cur request. But let's compare this request how it looks like if you open example.com in your browser and you open dev tools network inspector and then you can see those sec fetch

headers. They give you very detailed and very good information about where this request came from. also the target origin on the and the um the current origin um like is it a cross-side request basically so it basically tells you already okay this is cross-side request so what we now just need to do is clarifying that header and just look into the value as a defense in def and this is very easy to deploy you can just go in your engine X and write that rule I think this is how the rule can look like that you need to code so um very powerful has has someone already noticed those headers does in when you look in

Burp in your proxy and the notice but did you know what I do? Yeah. So that's that's a good thing. I always skip something. Um which slide are we on? Okay, this slide. Um now talking about uh again how they work. Imagine you are you have the site.ample and there's a chy JavaScript uh sending a fetch request to site.ample. So you can see the header telling you same origin but if you have evil.ample and you have an request to site.example it tells you cross- site and that's how you can then block this crossite reaches for tree basically. So this works really good at scale. Now uh let's talk about content security policy. You can see here a example of a

content security policy who has a content security policy deployed for his applications. Ah, I see a lot of heads. Who thinks you have a secure one? You think so? [laughter] That's the difference, isn't it? Uh, moving to a strict content security policy because this really is going to eliminate lots of the cross- types scripting vulnerabilities. And I want to take the example of Google again here because they have a strict content security policy for Gmail and they increased they increased the back bounty for Gmail to $50,000 just for a cross-ite scripting vulnerability because they didn't see any cross-ite scripting vulnerability report for over one year. So this is shows you how effective this can be if you move to a

strict content security policy. But uh it really is a a difficult balance how you can deploy it. That's I mean guess as a product security engineer is often the the biggest challenge. How can I deploy the CSP? Uh how can I uh yeah have the right balance between marketing and all that type of content that is hosted on my website and without breaking functionality. But here is really the focus that you start with a report only content security policy that you can then monitor your violations that you have and then move iteratively to a more secure content security policy. Uh here I I created like five steps um how you can uh do this like like I said

you start with a report only policy. This can be very strict one but then you um you generate some violations which you monitor and then you u basically add those violations or you you have to refactor some code and with the latest versions of content security policies you also have a script dynamic uh directive which allows you to be also more more um it's just got easier to deal with all those Google marketing it's those type of frameworks which you unfortunately have to embed to some of the websites So it's it's got easier and you need this uh this mix between reporting and iterating and moving to a strict content security policy and of course there will be some automation

this you need and this really depends on what application you're dealing with is it a legacy app or is a a modern front end with spar because uh you could also automatically some of the directives or the rules within your content security policy during the build and for example calculating hashes and nonses or adding nonses to your scripts that you have in the website. Then finally uh another modern browser security feature fe feature which I wanted to show you is trust types. Has anyone heard about trust types? I already that's good. Um so is is part of content security policy. You can see here the the rule how you can enable it. Um and it's actually very powerful uh

for example against DOMB based cross-ite scripting vulnerabilities. And this is very helpful if you work with legacy applications where you have maybe yeah lots of DOM based cross-ite scripting vulnerabilities and you don't want to refactor everything because trust types works like um a client side sanitizer or you can utilize it to a client side sanitizer. Unfortunately, it's not yet supported in Firefox but they're working on it right now but you already can use a polyfill to import it to Firefox. So it would work there if you use the polyfill. Um and um yeah uh to show you the concept of course you have so you you have those risky APIs like inner HTML out HTML evil those are the most

times the the the source of the DOM based crossite scripting vulnerability but now you can start write writing a wrapper around them or like a you can introduce a policy where you then use maybe a secure API like dom purify where you remove all malicious content from the JavaScript and that where you can um eliminate also DOM base crosset scripting and it's easier for uh to fix your legacy stuff basically just using that of course maybe maybe you don't need it if you already are on a very modern framework but most of us aren't and this is about deploying it everywhere uh here's here an example before um where you have like the vulnerable example you use inner HTML

but now you introduce that policy uh which is the wrapper um which uses the DOM purify library and then you have a safe uh function. So that way it's easier to refactor and if you set up some policies but this can be also used on in different different situations as well. So it's uh interesting that there's now like a client side sanitizer happening in the browser. Um yeah I wanted to finish this presentation with uh a quote from uh Feder B from Mozilla. Um so he was saying uh web security is increasing an opt-in approach leaving developers with both the opportunity and the responsibility to protect their applications. So it's it's everything which we just show uh which I just

showed you is about opting in because we can't break the web. They can't put something out there which changes standards. And I think thinking about cross-ite scripting vulnerability, one of the oldest vulnerabilities we have in the web, maybe it's a design flaw from the beginning, but we can't change, we can't break the web. So uh some takeaways. Um let's let's shift from reactive patching to this proactive security. um think about how you can uh implement them in your in your organization because it can be a real gamecher especially if you if you have one application that is has one vulner crossing vulnerability in my experience uh depending on the time and effort you put in you will be finding

more cross-ite scripting vulnerabilities in the same application. So having a content security policy is is very great and um adopting to those secure by default principles those uh headers um and um recognize the power of those uh browser le security features and with automation you can also scale you saw the example how Google did this with the engineix proxy and um yeah and uh let's let's start doing this commit to the buck class elimination. Yeah. Um, yeah, that's, uh, thank you for listening. Um, I hope you enjoy. [applause] Good. Are there any questions? It's fine. I'm I'm also there like >> you have like tools to craft CSV because they are hard to craft. You have like

>> Yeah. No, I I can repeat it. Yeah, do I have tools to craft CSP? Um, yes, it's very difficult. It's a challenge. I think there because it's also not a big topic for people like there is a add-on from Mozilla from April. It's called Mozilla Laboratory. It's only for Firefox, but this helps you generating a CSP. Uh, but then like crafting a CSP during automation maybe. So actually you need your own scripts in in in your CI/CD maybe that calculate hashes or add those nonses. So I I only have customuilt stuff for that approach. Um but there's there's some stuff but it's difficult and also another very good tool which will help you uh is the

Google CSP evaluator which is also giving you some feedback about the security and the safety of your CSP. Great. >> Yes. You wrote it. >> Ah, you wrote it. >> Amazing. >> Good.

>> Yeah, you wrote it. Okay. Amazing. It's good. Good. I will be there also in the hallway if you have any questions. So, it's good.