Ep. 115: Is CSRF Really Dead?

In 2020, Chrome will default the SameSite attribute to Lax on all cookies. SameSite helps mitigate CSRF, but does that mean CSRF is Dead?

For more info go to https://www.developsec.com or follow us on twitter (@developsec).

Join the conversations.. join our slack channel. Email james@developsec.com for an invitation.

 DevelopSec provides application security training to add value to your application security program. Contact us today to see how we can help.

Transcript:

On this episode, James talks about the new same site default that’s going to be going on in 2020, and CSRF.

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 115 of the DevelopSec podcast. I’m your host, James and today I want to talk about CSRF or cross site request forgery, and ask a question in 2020, will CSRF be dead? Is it dead today? I’d like to say probably not, definitely not. CSRF is still out there. But I have seen some posts out there saying, hey, CSRF is dead. A lot of it really revolving around the use of the same site attribute on cookies.

So I’ve talked about same site before but same site is this idea that basically what you’re saying is, when I create this cookie, I’m going to set the same site so that if I’m requesting the application from a different domains or from a different application, the browser will not send the cookie to the requested application, if same site is set. So this really helps us with cross site request forgery, because that’s basically how cross site request forgery works. Right? The idea that I’m on site one, and I have created an image tag for an example, that the image tag is a link to transfer money out on site two that when you click it on site, one, it makes a request to site two, which you’re logged into already, that’s a caveat there.

And when the browser sees the request to site to it says, Oh, I have cookies for that, I will go ahead and send those along with it. So this is how cross site request forgery works. And, of course, we’ve been adding all kinds of mitigations to try to reduce this risk, typically, the nonce, but one of the things that’s more of a recent thing is the same site flag.

So same site, when you set it on there basically tells it, hey, if you’re not calling me from the same site, don’t send the cookie with it. So this is a great mitigation as long as the browser supports doing that, and right now, same site is something that the application developer has to set. So I have to as the developer of my application, say, hey, on this cookie, I want to set same side to either lax or strict. And as the names would imply, lax is a little bit more loose. So things like an a tag or a link tag, if I have a link to the site, so I’m going to navigate at a top level domain, then, with lax, it’ll still send the cookies, even if it’s from a different site, because I’m navigating full top level with strict I would not so strict, unless you’re navigating from the current site, it’s not going to go ahead and send those cookies with it.

So that’s kind of that difference there. So lax gives a little bit more leeway. And there is a little bit more room for cross site request forgery to still exist, I actually had this on an application really that that risk there is really focused around if for some reason you’re making modification requests, using get typically. So that’s really where we kind of get that key there is are you using GET requests to do this, because those are what we can put into items that are going to be top level domain type changes. So that’s kind of the bigger risks that we have around there. There may be some other ones around that. But that’s basically what same site is doing.

So right now, I have to set that as a developer, to be able to set this on my application. And again, just because I saw that same site doesn’t necessarily mean I’ve fully removed the capability of CSRF. But as a great mitigating control that we can put out there, in addition to things like nonces and such. So SameSite is great. Well, Chrome has announced that in 2020, they’re going to change it so that all the cookies that they see they’re going to default to the same site lax everywhere, right, that’ll be the default.

So if it sees a cookie come down and same sites not set, it’ll automatically set the cookie to LAX. So they’re adding this protection in now I’m not necessarily the biggest fan of browsers trying to fix something that developers should be doing. But this is an issue where this could help reduce a lot of the potential for CSRF. The problem with that is that it’s again, still browser specific. So if Chrome does it, and they did default it to this value, well, that doesn’t mean I don’t have to still not do something as a developer, because that doesn’t mean that Firefox is doing it or Safari or edge or whatever other browsers people may be using. Right.

So as I say, with anything that’s browser based like that, when you talk about even like cross site scripting protections, from a browser based level, you still have to do your output encoding, don’t rely on the browser to solve your problems. I like to say pretty much the same thing here. Don’t rely on the browser to solve your cross site request forgery problems. I think this is a great thing that they’re defaulting it to a more secure setting. And you know, this is going to force people that, hey, you’re going to have to opt out of the secure setting if you need to, which would greatly reduce the number of apps that are actually vulnerable. So it’s a good thing that we’re doing this. But at the same time, as you’re develop, don’t just rely on the fact that the browser is going to do this.

But so same site by default in 2020. With Chrome, I’m assuming at some point, that Firefox and Internet Explorer and Safari will follow along suit with this, but there hasn’t been any timelines listed as to when they would default this to actually happen. So right now, fortunately, as a user, you can actually go in to both Chrome and Firefox, I haven’t checked any of the other browsers but both Chrome and Firefox you can actually go in and change settings there, they’re already there, just by default turned off, to turn on lax by default for the same site flag. And in Firefox, you can do that under the about config settings and just look for, I just did a search for same site. And you’ll find two values in there, you’ll find network cookie dot same site dot lax by default, and network cookie dot same site dot none requires secure. So that’s how we do it. In Firefox.

I’ve explained both of those in just one second. But let me just say, in Chrome how to do it in Chrome, we don’t have the about config. Instead, you go to Chrome://flags. And then you can do a search again, for same site. And there’s two settings in there same site by default for cookies. And cookies without same site must be secure. So the first one, it’s the same on both the lax by default, and same type by default cookies. That’s saying, Look, any cookies that come down, I want you to automatically set same site to be lax. Alright, so it’s going to set it, if the developer didn’t do it, the browser is going to do it for you. Alright, so we’ve got that covered.

The next thing is, and this is kind of a requirement that they’re putting into Chrome when they start setting this by default, is that if you’re not going to, if you don’t want to set the same site flag for some reason, then there’s an additional requirement, you can’t just set it to unset, which I think is they’re calling it none. So you just do SameSite, none, instead of just doing same site, none, you also have to make sure that that cookie has the secure flag set on it. So you can’t just set a cookie and say, No, you know, I don’t care about SameSite, I’m going to set it to none. If it doesn’t have the secure flag, the browser will not respect that. And it’ll go ahead and set the same site lax on it.

So that’s kind of one of those caveats that’s being put around this, that if you’re going to set it to none. Now you have to also make sure that you set the secure flag, which we should have the secure flag anyway. Because if you’re running a site that’s not on HTTPS, you know what that was, like? 10 years ago, everything should be HTTPS by now. So that shouldn’t be an issue secure flag should be one of those defaults.

So it’s interesting to see that we’re getting this by default, we’re going to start forcing these preferences, I’ll be honest with you, I’d love to be able to see that same thing happen with the secure flag, I’d love to see the same thing happened with the HTTPonly flag, where we go in there and we say, You know what, by default, these are going to get it and unless as a developer, you go in and explicitly say, I don’t want this flag, then they’re going to default it to a more secure setting.

So now unless you’re specifically going to go out there and say, Hey, we’re going to support HTTPS, so I need to turn the secure flag off. Then by default, the browser’s just gonna say, You know what, I’m not gonna transmit this unless it’s over a secure channel, and leave that up to the application to turn that off. You know, same thing what we’re doing here. So like I said, there is a way to be able to turn it off. So if you’re developing your application if for some reason, you need to make cross site requests within your application need those cookies to be transmitted. appropriately, then you can set same site equal to none. But you have to set the cookie to also be secure. But one thing I want to point out when looking at this and talking about this is that, again, I’m a fan of, hey, look, let’s make it more secure by default. And then lets you change it back the other way.

So if you’re somebody that’s developing, and you have no idea what the same site flag is that I’m talking about, and you’re a developer out there working on your applications, and you got cookies, if you’re not already in an application framework, that’s going to default your cookies for you. For example, identity server with .net core automatically set SameSite lax for you as well, if you’re not already doing that, and you’ve got a site that all of a sudden, when these browsers start making this change, by default, things aren’t working right. It could be the fact that the cookies now have same site on them. And they’re not being transmitted like you expect them to be. And I was actually doing a little bit of searching around before I wrote the blog post about this and did the podcast. And I saw some people complaining or not necessarily complaining, but you know, writing out there saying, hey, look, I had this issue, you know, I was writing an app that runs on a mobile device. And for some reason, stuff wasn’t working as expected. And it came out that oh, wait a minute, same site was being set and they didn’t realize it. And that was causing an issue with their app.

So while I’m a huge fan of the idea that, hey, look, we’re going to default this across the board that’s really going to help protect things. If you’re not staying up to speed on this type of stuff, that change could come out. And that could have a drastic effect on your application potentially. And you might not be aware of why that is. So make sure we spread this around, make sure everybody understands what same site is what it’s used for, understand, you know, what types of activities is going to affect within your application, so that you can get ahead of this.

Now I know there was an announcement, at least with dotnet core, that they are updating something that kind of coincides with this. So you can actually have instead of SameSite, LAX or same site, strict you do have there’ll be another option for same site none to be able to turn it off, or be able to explicitly set it because typically, if you were to say same site, none, you basically just don’t send the same site attribute, right. So that just wouldn’t be part of that cookie. Well, now, it’ll actually come down and it’ll be there, it’s just going to be none instead of lax or strict.

So we need to be aware of that, that that something is going to be coming down and is going to be on by default, and some of the browsers which could cause some issues. So that’s one of the reasons I really want to talk about this, like one, I love the fact that, you know, we’re chopping down here at the attack surface, really, of CSRF. But to for those that might have something going on that this might affect, we want to get ahead of this early, if you’ve got a site that you’re already dealing with. And you’ve not messed around with same site, I would recommend in a testing environment, start playing around setting all your cookies to same site lax, and see how that goes. You know, make sure the site’s working as you expect it, all that stuff. Because if it doesn’t work, as you expect it, there’s for some reason to read for you to turn it off, then at least you can get ahead of that. And you can start declaring Hey, same site none before the browser start defaulting it for you.

If you have questions about that, looking for more information or anything like that, feel free to reach out James at DevelopSec.com Happy to talk about it, I do have the blog post up that actually goes through and shows where you can set these settings in Chrome. And in Firefox, if you want to try it out. Now, that might be one of the ways you could test it within your testing environment. So if you’re a software tester out there, go in and maybe set those for a little bit on one of your browsers, and test your app, make sure it’s working as you expect it to be working. You know, just to make sure that everything works as expected, because you don’t want to get to a point where a new update comes out. And all of a sudden now you’ve got a whole bunch of tech support issues. As people are trying to reach in and say, Hey, stuffs not working and you’re you’re scrambling trying to figure out what the heck is going on. This is type of stuff that wallet tries, you know, goes around the security community a lot. I’m not sure how well it makes it deep into the actual development community. So definitely something to think about. So I hope you enjoyed this episode. If other topics you want to hear, feel free to reach out, let me know. Otherwise, we’ll catch you on the next episode. Thanks for listening.

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