Do you rely on the browser to protect your application from Cross-Site Scripting? Over the years, many of the popular browsers attempted to create these XSS filters to help reduce the risk of the vulnerability. Unfortunately, over the years we have seen a lot of bypasses to these filters. Chrome announced they are removing their XSS Auditor. Hear some of our thoughts on the changes.
Listen to the Episode:
On this episode James talks about Chrome dropping the XSS auditor, cross site scripting filter built in to the browser. Tackling the challenge to integrate security into the development process, looking for insights, answers, and practical solutions to avoid getting overwhelmed. Welcome to the DevelopSec podcast where our focus is your success in securing and improving development processes.
And here is your host, James Jardine.
Hey, everyone, welcome to episode 116 of the DevelopSec podcast. I am James and today I want to talk a little bit about cross site scripting. Now with cross site scripting being the main topic, but if you’ve been watching the browser’s over the past few years, maybe you’ve seen some of the built in cross site scripting protections or filters that some of the browser’s have included in there. And we’ve kind of seen them drop off a little bit over the years as well.
But lately, we just saw that Chrome is now removing their built-in cross site scripting filter, also known as the XSS Auditor feature, Chrome 78, that feature has now been fully removed from the browser. So we no longer have it in there.
That was years ago, maybe like eight or nine years ago, it’s good long time ago, right? And that same time Firefox was starting to put in some of these filters, and chrome put them in, I think safaris got, like everybody kind of started putting these cross site scripting filters in. And then what we found out was that people were bypassing them all over the place.
First, these filters are not that sophisticated. Quite honestly, typically, what they do is they’re looking for in most situations, reflected cross site scripting. So when we talk about that we’re talking about it’s in the URL, alright, it’s in the request. And we’re seeing that exact same string, showing up someplace within the actual source of the page. If for some reason I have a search query, and I put script alert nine, and the page actually has script alert nine in it, then the browser’s going to detect that and assume and say, Hey, this might be cross site scripting, I’m going to go ahead and block this. And in most cases, what they would do is basically kind of change one of the characters or something to make it benign.
So it wouldn’t actually execute. And it would just kind of be there. So we’ve got this capability. It’s not super advanced, but it does provide a small level of protection, and I get it, I mean, I’m not a huge fan of the browser trying to fix my problems. But you know, I see it, this is a good way, or kind of a way to get the most effectiveness in trying to help mitigate a very common problem known as cross site scripting. So the browser’s put this in, and then of course, we start seeing bypasses come up everywhere for these, you know, I found a way to bypass their filter. And people’s names are built off of this. And you know, I don’t know I’ve always hated the bypass of it, because let’s be honest, ultimately, it’s the application developer’s job or responsibilities to actually be doing proper outputting coding, so that the browser shouldn’t have to be putting these type of restrictions in there. Because the app should be taken care of that right? We should be knowing what we’re sending down and if we’re sending down untrusted input, it should be properly output encoded, so that way the browser will understand what it is because outside of reflective the browser doesn’t know what’s supposed to be there, what’s not supposed to be there, when it all comes down from the server. That’s all one big piece of source. Right?
There’s no way for the browser to know the developer didn’t intend for this to happen. Now, of course, we do have things like CSP or content security policy that we can do, which kind of replaces really what I guess they were trying to do with this. And CSP does a whole lot more than what this does. But, now we’re seeing that sometimes these ideas don’t work. So well, and Firefox pulled it a long time ago, I’m actually kind of surprised that Chrome took so long to actually pull it, and again, I understand the reasons why they’re pulling this out. If we’re developers, we’re testers, stuff like that, then, we have to be looking at our application and understanding how our data flows. So we can protect that data when it comes down before making it the browsers problem.
Now, of course, this isn’t the only time we see browsers trying to help out like content security policy, let’s be honest, I mean, that’s a browser directive that’s there to help us kind of solve this problem. You have got other things like, the secure flag, or the HTTP only flags that we set on cookies that are browser directives that are here, just sit there and say, Hey, we want the browser to handle this.
I don’t want to allow inline scripts within my page, it has to be referenced through a link and brought in so there’s lots more control over that. That’s much easier to verify, than trying to rely on the browser to say, hey, there’s a script tag. Is it malicious is not malicious? Is it supposed to be there? Is it not supposed to be there? That’s much more difficult, right? It’s not cut and dry. When we start talking about CSP and stuff like that. Now it’s becoming much more cut and dry, or say, Hey, we’re only going to allow scraps from domain XYZ, or we’re going to only do this from here. And it’s just much more definitive, and what we’re trying to do.
When we talk about the XSS auditor, we see this disappearing, this was controlled by a response header, the X-XSS-PROTECTION header that we get set coming down, if you didn’t set it, it defaulted to one, which is on. by default, your sites are protected from this, or not protected from it. But it’s enabled, so that if the browser supports a built in access filter, it’ll be enabled by default, unless we set it to zero specifically saying, Hey, we don’t want to have this on.
So of course, over the years, our recommendations are best practices, all these guidelines all say, Hey, make sure you set X-XSS-PROTECTION to 1, it’s also got reporting capability, although I don’t know if anybody uses the reporting capability, but it does have that capability. But set it to one, right that we always want to make sure if you’re doing response centers, make sure you have this header set. But does that change now? And I’ve always said, when I do my training classes, you know, hey, here’s this header. But keep in mind, it’s not really a solution. Because Firefox doesn’t support it like other browsers might not support it. It’s supported in Chrome. But that’s only going to help you for the people that are in Chrome, or maybe it’s a I think the browser compatibilities, that IE eight or something, it might be supporting this or might be supported in Safari, but it’s not supported across the board the same way.
We can’t allow us to kind of fall into that simplicity and say, Oh, I’m safe. I have this protection header. So we’re going to use the filter, right? We’re not going to do that. Yes, it’s fine. We can set it. But just realize that that’s really just kind of that fallback. I’ve added an extra layer, just in case something slips through. Maybe somebody is on Chrome, and maybe they’ll get protected from it, or maybe it on this browser. It’s just that okay, but now that we’re seeing chrome drop it, there still are other browsers that support it. Like I said, I think Safari lists on the compatibility charts have already said show support, or old version of IE eight.
And some of the mobile browsers are still supporting. I think it even said iOS Safari supports it. So there still are a couple things to do. So does that mean that we’re not going to send them anymore, I wouldn’t recommend not setting it, just because there are some browsers doing it. And you may still have people that are on older browsers. It doesn’t mean hey, let’s just stop that recommendation and do it, I still leave it in my guidelines, I still leave it in my training, that we’re doing it. But it adds more discussion around the fact that, hey, here is this piece, they kind of reminds me back of when we just think SQL injection, like store procedures is your solution.
That’s all you need to do. And I was like, No, that’s not true, because stored procedures can be vulnerable as well. Same thing here, alright, we have something that can help reduce the risk or mitigate in certain situations, but it’s not across the board. And if you can’t implement CSP, if you’re not to that point, hopefully new apps, you built it. So you can do CSP can’t do that type of stuff, right, then you’re still locked into. And even with CSP, you’re still locked into, I have to properly output encode my data. So that way, I don’t have cross site scripting flaws.
So number one thing, every time we’re talking about cross site scripting is output encoding, these other things are just additional pieces that can help us that if for some reason a piece is missed, if there’s something that’s not there, then hopefully, we’ll have a little bit of backup a little bit of protection. But ultimately, it’s our responsibility as developers, to when we’re sending output back down, understanding the context that output is in, and then properly encoding it for that context, to make sure that we’re protecting everything going through.
That’s not the browser’s job, the browsers are great. And thank you for helping try to help mitigate some of this. But remember, ultimately, it’s your job and responsibility to make sure that you’re sending data down how it should be sent down. I think it’s interesting that we see that this is being dropped. Again, I think it’s overdue a bit, just because of kind of some of the ways it’s handled, and that’s nothing against the browser. I think browsers did a good job trying to implement something that would help reduce the risk around a flaw that, quite honestly, is one of the most seen that we see. So good that we’re seeing something like that come out. But you know, things are changing things are, are going in different directions. And so now we’re seeing that drop.
I’m not recommending not setting that header anymore, still set it, you know, make sure that you’re explicitly setting it to one just realize that it’s not going to fully protect you, it never was going to fully protect you, right, we can’t rely on the browser to try to perform all of our XSS protections, that’s just not going to work. Check it out, I’ll put some links in the notes talking about linking out to Chrome talking about this being removed, and maybe the browser compatibility, so you can see where it’s also connected. But definitely check it out. Think about it, be aware that the changes are coming.
It really shouldn’t affect too much to be honest. But this is definitely something we need to be aware of within our systems, to know what’s there, what’s not there and how things work. So I appreciate everybody tuning in, listening if questions, things coming up on your mind that you’re not sure about anything appsec related. Feel free to reach out. I’m happy to try to answer any questions you have. You know if there’s topics you have, that’s great. Other information, just go out and check it out at developsec.com. And if you have questions, just reach out to me James@ developsec.com. Again, happy to have those conversations with you. So thanks again for listening, and we’ll catch you on the next episode.
You have been listening to the developsec podcast with James Jardine. To find out more about how we can help you with application security. Follow us on Twitter @developsec, or check out our website at www.developsec.com