James Jardine:
On this episode of the DevelopSec Podcast, James talks about some of the new changes coming out to the Chrome browser regarding same site and mixed content. 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 the DevelopSec podcast. This is James and we are on episode 117. First episode for 2020. I'm looking forward to a new year. Hopefully you're looking forward to it as well. Hopefully things are going well. Hopefully last year was well for you.

James Jardine:
And I'm hoping that we have a lot of great discussion and learn a lot throughout this year when it comes to application security and secure development. Today I want to talk a little bit about some of the different changes that are coming out, especially in the Chrome browser, and why changes matter like this when they're coming out when a browser starts implementing them. Because a lot of this stuff typically should be implemented to the application side, but the browser has some role to play here. And some browsers are taking more of a leap than others. Some just do it a little bit earlier than others. But we see these changes coming through to help kind of protect the users as they use these sites. And we saw this recently with Chrome, you know, dropping XSS Auditor, right? That was something that was added in and then they kind of removed it back out because, you know, it was really kind of difficult to handle. It's much more complex to implement effectively than it might seem on the outside.

James Jardine:
So today, I want to talk kind of quickly about 2 different things. 1 we already talked about. And That first thing we already talked about was Chrome was going to start doing same site by default on your cookies. So we'll talk about that in just a moment. And then they actually just released out this month, some updates on some changes they're making as far as mixed content, especially when we talk about downloaded files. So that's something new, we haven't talked about that yet, so we'll talk about that in just a moment. But I'm gonna go back and just give a quick update on the same site situation. So we have the same site flag or the attribute that we can set on our cookies.

James Jardine:
We set this value to help protect our applications from cross-site request forgery, so that in the event that you're using cookies for your session management, your authentication, somebody makes a request to your site from another site, the browsers won't actually submit those cookies for your site to your site because it wasn't made from the same site, hence the name same site. So when we designate those as same site cookies, we're telling the browser only submit these cookies if my site currently is requesting my site. If I'm on some other site, I'm over on develop sec and I make a request to Jardine Software, and Jardine Software has set same site cookies, then the browser will know not to send those cookies with that request to Jardine Software because it didn't come from within the same site. And again, this is all to help remediate and reduce the risk of cross-site request forgery where if I don't have anything else in place, and we should have something like a nonce or some sort of request validation token that we're making sure that we can't kind of replay these requests and every request is unique. If you don't have that, then this is going to help kind of stop that because no longer will you be authenticated to be able to do this because those authentication cookies won't go with the request. So this is a great thing that we're seeing out here, but that doesn't mean that doesn't come with its cons. You know, we still have to make sure that we're checking and validating that our systems are gonna work okay if the same site flag is set to a value that we haven't configured it for. By default, same site isn't set.

James Jardine:
So basically, it's set to none. So your cookies will go. It doesn't matter who's requesting them. As long as it's a request to your site, your cookies will go with it. When we said same site, whether it's strict or lax, we've got 2 different options there. And we have a whole other podcast, I think, that talks about that. Right now, we're saying we're putting limitations on when those cookies will be sent. So now we're starting to see browsers, especially Chrome, which is getting ready to start doing it very soon, they're going to start saying, listen, I'm going to default.

James Jardine:
And if you don't tell me what you want same site to be, then I'm going to default that cookie to be same site lacks. And we're going to have some restrictions on that. And it's not going to work maybe as you expected it. So I encourage you, if you haven't done so already, to go out and test to make sure that your site's gonna work with same site lax being configured. And if it's not, You're gonna have to go in, you're gonna have to actually specifically state that it's gonna be same site, none, and you're gonna have to make sure that you're serving up over HTTPS, which you should be anyway, right? The cookie has to be secure as well. So make sure you have the secure flag there, and make sure that you have it specified as none if you don't wanna use that. I think most cases, you're typically okay. Like a lot of your cookies are gonna be okay if they're not going cross-site.

James Jardine:
So, you know, only very limited cookies actually get transferred across sites like that. So there are ways and I actually have a blog out there I'll put a reference to it that goes through how you can actually configure your browser whether it's Firefox or Chrome right now to actually force this default to set it to lax and be able to test your site to make sure that everything works as expected before the actual push happens and goes down to the users and everybody starts having same site default to lax. Now again remember I think right now I haven't heard of plans for Firefox to default this yet, but I do know that Chrome has stated they are going to start doing it and they're going to start doing it soon. So we want to make sure that our apps are ready for this. So it's a pretty simple configuration change in your browser to be able to set it to auto default already for you and you can go through and retest your apps to make sure that everything works as expected. Now the second piece that we have that we're going to start seeing getting blocked is they're really trying to cut down and block mixed content types. So if I've got a site that's HTTPS but I'm loading content that's HTTP, so whether that's a downloaded file, whether that's images, whether that's PDF files, any of that stuff, that's mixed content if we have some over HTTPS and some over HTTP. Well, Chrome's kind of pushing their timeline here to say, look, we're gonna start blocking this mixed content so that way people don't think because a lot of this stuff, you don't see the behind the scenes.

James Jardine:
All right, when I test an app, I'm in a proxy, I can see every request and I can see whether it's secure or not secure. But as a regular user, You don't see that. You see the main URL. So if I'm on developsec.com and it's HTTPS, then my assumption is that everything I'm accessing on there is also HTTPS. So it's secure. Somebody can't just man in the middle it. They can't modify it, anything like that. So here, and some browsers will give you kind of a warning, they used to give a warning anyway, to show like, hey, not everything on this page is secure.

James Jardine:
And it'll list the page in general as insecure, but doesn't block you from being able to do anything. Well, starting in Chrome 83, which I think is due more of like June, I think? I think it says, yeah, really it's June 2020 for 83. They're going to start blocking file downloads, basically. So like exes, APK files, something that is an executable, they're gonna start blocking that if the page you're on is HTTPS but the file you're requesting is over HTTP. So right we have that mixed content, we're gonna start blocking that, and they're not gonna allow that content to come down. And again, this is all to make sure that, you know, you're not sitting on a site that looks secure, but then it's going to insecure file downloads behind the scenes, but you're assuming that it's secure, because you see the HTTPS up there in the URL. So then starting in Chrome 84, they have this whole timeline online. I'll have the link to the article for this.

James Jardine:
Starting in 84, things like archives are gonna start getting blocked. So your zip files, your ISOs, that type of stuff will now start getting blocked if it meets that criteria. And then out on Chrome 85, we start seeing other non safe types, right? So these are like your PDFs, your documents, your Excel, you know, more like application type files. And then 86 and later, they're actually gonna start blocking as well, like images, audio, video, text, really anything. So I can assume only that Chrome 86 and later, there will be no more mixed content allowed at all. And you'll have to be making sure that everything you're referencing is also HTTPS on that. And you know, we should be using HTTPS. It's It's not that performance hit that it used to be back in the day.

James Jardine:
But it's also important for us to make sure that we're aware of some of these changes that are coming up down the line within the browsers. Because while we work in our application, and yes, there's lots of things that occur in a browser that can cause us issues. You know, anybody that has to create their application for all the different browsers, whether you do Firefox or Chrome or Safari or Edge, trying to navigate all the little quirks that exist in there can sometimes be a pain. And now we've got on top of that, some of these things are adding for a security perspective that we would not be as much up on as we normally are for some of the other things. So here's that chance to be able to go out and understand some of these changes and then start looking at our sites and start seeing, do we have anything that's going to be affected by this change? And hopefully the sooner the better as far as trying to get some of those things resolved because the last thing you want, all of a sudden a new update drops out there and you got users that no longer can access certain things. Like a feature's not working and you're not sure why, right? You go try it in another browser, it works just fine. Or you try it in your browser, which hasn't updated yet and it works just fine, but other users are getting issues. Trying to troubleshoot that can be a pain.

James Jardine:
So finding ways to be able to go through, kind of get ahead of that and know, hey, these are the changes that are coming down the pipe. This is what's coming out of this browser. So we want to kind of make sure we're covered against this the whole way through. Let's make sure that we're doing some of this stuff. And this is a great way sometimes for us to kind of be forced into changes that we should be doing, but we don't have a priority to do that right now. For example, the same site, Even though a lot of the, some of the frameworks now anyway, are defaulting that. So I believe in .NET Core, right? They'll default like your session cookies or your authentication cookies and actually default SameSite Lacks for you on those. But there's still a lot of frameworks that don't do that.

James Jardine:
So this is going to be something that's going to be kind of pushed out there. Now, I don't recommend leaving this up for the browser to enforce that. So let's use that quick example for SameSite. If I'm an app developer and I don't set the same side attribute on my cookies, because I know, oh, well, Chrome will do that for me, but that doesn't mean that Safari will do it for you. It doesn't mean that Firefox will do it for you. So if you're not setting it yourself, you're not going to be completely covered. And that's going to run into the risk of not actually being mitigated and you being open to a vulnerability. So just keep that in mind as you go through looking at these things, don't rely on the browser.

James Jardine:
Make sure that you're actually explicitly setting these things that the browser is trying to help you protect against. So I appreciate everybody for listening. If you got ideas, send them to me, james.developsec.com. Otherwise I'll catch you on the next episode. I hope everybody has a great day and we'll see you when we record again. 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 Follow us on Twitter at DevelopSec or check out our website at www.developsec.com