Browsers play a role in web application security, but where does their responsibility stop and the developer’s start? In this episode, we are going to discuss a few changes happening in the Chrome browser, that change security by default.
Listen to the Episode:
Chrome has announced a few changes that we need to watch out for in the near future. We previously talked about the default value for samesite that is coming up fast. I wrote about this here: https://www.jardinesoftware.net/2019/10/28/samesite-by-default-in-2020/
This change could impact any application and as developers we should be aware of security defaults in the browsers.
Also, they are getting ready to start blocking mixed content downloads:
For more info go to https://www.developsec.com or follow us on twitter (@developsec).
On this episode of the DevelopSec podcast, James talks about some of the new changes coming out to the Chrome browser, regarding samesite and mixed content. 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 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. 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 on the application side. But the browser has some role to play here. And you know, 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 dropping XSS auditor. 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.
So today I want to talk kind of quickly about two different things, one we already talked about, and that first thing we already talked about was Chrome was going to start doing samesite 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 going go back and just give a quick update on the samesite situation. So we have the samesite flag or the attribute that we can set on our cookies, we set this value to help protect our applications from cross site request forgery, so that in the event that using cookies for your session management, your authentication, somebody makes a request to your site from another site, the browser’s won’t actually submit those cookies for your site to their site, because it wasn’t made from the same site, hence the name, samesite.
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 DevelopSec and I make a request to Jardine software and Jardine software has set SameSite 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.
This is a great thing that we’re seeing out here. But that doesn’t mean that doesn’t come with its cons. We still have to make sure that we’re checking and validating that our systems are going to work. If the samesite flag is set to a value that we haven’t configured it for, by default, samesite is not set. So basically, it’s set to None, right? So your cookies will go 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 set same site, whether it’s strict or lax, we have two different options there. We have a whole other podcast, I think that talks about that. All 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 to update Soon they’re going to start saying, listen, I’m going to default. And if you don’t tell me what you want samesite to be, then I’m going to default that cookie to be SameSite-lax. And we’re going to have some restrictions on that. And it’s not going to work maybe as you expected it.
I encourage you, if you haven’t done so already, to go out and test to make sure that your site is going to work with samesite-lax being configured. And if it’s not, you’re going to have to go in, you’re going to have to actually specifically state that it’s going to be samesite-none. And you’re going to 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 want to use that.
I think in most cases, you’re typically okay, like a lot of cookies are going to be okay if they’re not going cross-site. 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 on 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 you know, kind of pushing their timeline here to say, look, we’re going to 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, 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 develop sec.com, and it’s HTTPS, then my assumption is that everything I’m accessing on there is also HTTPS. So that’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. And or 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 do more like June, I think, I think it says yeah, released June 2020. They’re going to start blocking, file downloads, basically. So like exe’s, APK files, something that is an executable, they’re going to 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 going to start blocking that. And they’re not going to 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 have the link to the article for this. Starting an ad for things like archives are going to 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 in 86 and later, they’re actually going to 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 not that performance hit that it used to be back in the day. 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 exists in there can sometimes be a pain.
And now we’ve got on top of that, you know, 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, you know, 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 obviously, you get users that no longer can access certain things like a feature is 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. 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 just 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 you know, this is a great way, sometimes for us to kind of be forced into changes that we should be doing. But we you know, don’t have like a priority to do that right now.
For example, the samesite, even though a lot of the some of the frameworks now anyway, are defaulting that. I believe in dotnet core, right, they’ll default like your session cookies, or your authentication cookies, and actually default SameSite lax for you on those. But there’s still a lot of frameworks that don’t do that. 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 samesite 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.
Just keep that in mind as you go through looking at these things. Don’t rely on the browser, make sure that you’re actually explicitly setting these things that the browser is trying to help you protect against.
I appreciate everybody for listening. If you got ideas, send them to me, firstname.lastname@example.org. 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 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.