On this episode, James talks about Chrome dropping the XSS Auditor cross-site scripting filter built into the browser. Tackling the challenge to integrate security into the development process? Looking for insights, answers, and practical solutions to avoid getting overwhelmed? 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. Not with really cross-site scripting being the main topic, but if you've been watching, you know, the browsers Over the past few years, maybe you've seen some of the built-in cross-site scripting protections or filters that some of the browsers 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. So I want to talk about why does that matter, what it did, and how that affects us. You know, if we go back, you know, years ago, browsers, it kind of all of them started building in these filters. I feel like, you know, I remember even IE7 when it first got released, I think had a filter built into it. There was either 7 or 8, because I remember actually working in an organization where we had a time clock type of application. And for some reason, this application decided that sending JavaScript through the URL was a good idea. And sure enough, we were actually being held back from updating our browsers to the next latest current version of browser for Internet Explorer at the time, because that application wouldn't work in the latest version. You had to actually go in and figure out how to turn off that filter. And it was kind of a big whoop-de-doo trying to get it to work. So, and that was years ago, maybe like 8 or 9 years ago. I mean, it was a good long time ago, right? You know, and at the same time, Firefox was starting to put in some of these filters. We had Chrome put them in, I think Safari's got them, like everybody kind of started putting these cross-site scripting filters in. And then what we found out was, is that people were bypassing them all over the place. So let's get it straight 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, right, it's in the request and we're seeing that exact same string showing up someplace within the actual source of the page. So, you know, if for some reason I have a search query and I put script alert 9, and the page actually has script alert 9 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 1 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. You know, I mean, I'm not a huge fan of the browser trying to fix my problems, but 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 browsers put this in, and then of course we start seeing bypasses come up everywhere for these. You know, oh, I found a way to bypass their filter, and you know, 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 responsibility to actually be doing proper output encoding so that the browser shouldn't have to be putting these type of restrictions in there because the app should be taking 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 outputting coded. 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 1 big piece of source, right? There's no way for the browser to know, oh, the developer didn't intend for this to happen. Now of course, we do have things like CSB, our content security policy that we can do, which kind of replaces, you know, really what I guess they were trying to do with this. And, you know, CSB does a whole lot more than what this does. But, you know, now we're seeing that, you know, 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, you know, and again, I understand the reasons why they're pulling this out. If we're developers, you know, we're testers, stuff like that, then, you know, 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 browser's problem. Now, of course, this isn't the only time we see browsers trying to help out, right? 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 know, you've 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 to turn and say, hey, we want the browser to handle this. So it's not the first time we've ever seen this happen, but it is, I think, a little bit different. You know, you look at a secure flag and, you know, it's making it very simple of what it does. If it's a secure connection, I'll send the cookie. If it's not a secure connection, I won't send the cookie. It's 1 or the other. HTTP only. Do I allow JavaScript access? Do I not allow JavaScript access? These are very simple things to be able to control. And then if you get into like CSP, We're not getting down to, hey, is this a script or is this not a script? You know, is this malicious? Is it not malicious? You're instead saying, hey, look, here's all the type of content I have, and here's how I want to put restrictions about that content. 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 it 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. And we're saying, hey, we're only going to allow scripts 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. So when we talk about the XSS auditor, you know, we see this disappearing. This was controlled by a response header. The X dash X SS dash protection header that we get set coming down. If you didn't set it, it defaulted to 1, which is on. So 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 XSS filter, it'll be enabled by default unless we set it to 0, specifically saying, hey, we don't wanna have this on. So of course, over the years, our recommendations, our best practices, all these guidelines all say, hey, make sure you set 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 1, right? That we always want to make sure if you're doing response headers, 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. You know, like other browsers might not support it. It's supported in Chrome, but that's only gonna help you for the people that are in Chrome. Or maybe it's, I think the browser compatibility is at IE8 or something. You know, it might be supported in this, or it might be supported in Safari, but it's not supported across the board the same way. So 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 gonna use the built-in, right? We're not gonna 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's 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 chart. Safari shows support our old version of ie8 And also some of the mobile browsers are still supporting. I think it even said iOS Safari supports it. So there still are a couple of things to do. So does that mean that we're not gonna set it 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. So it doesn't mean, hey, let's just stop that recommendation and don't 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. It kind of reminds me back of when we used to 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 store procedures can be vulnerable as well. Same thing here. All right, we have something that can help reduce the risk or mitigate in certain situations, but it's not across the board. All right. And if you can't implement CSP, if you're not to that point, hopefully new apps, you've built it so you can do CSP. If you 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 and code my data so that way I don't have cross-site scripting flaws. So number 1 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's 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. So 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 1 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 going in different directions, And so now we're seeing that drop. I'm not, again, I'm not recommending not setting that header anymore, still set it, make sure that you're explicitly setting it to 1, 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. It's just not going to work. So check it out. I'll put some links in the notes talking about, you know, 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 you have 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. 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.at.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 Jardim. To find out more about how we can help you with application security, follow us on Twitter, at DevelopSec, or check out our website at www.developsec.com.