James. 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 Develop SEC podcast. I am 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 domain so 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. 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 Two, 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 nons. 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 this 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, SameSite is something that the application developer has to set. So I have to, as a developer of my application, say, hey, on this cookie, I want to set Same Site to either Lax or Strict. And as the names would imply, lax is a little bit more loose. So things like an A tag, 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 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 risk that we have around there. There may be some other ones around that, but that's basically what SameSite 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 set SameSite doesn't necessarily mean I've fully removed the capability of CSRF, but it's a great Mitigating control that we can put out there in addition to things like nonsense and such. So same site 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 Same Site lacks everywhere. Right? That'll be the default. So if it sees a cookie come down and Same Site is 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 your developers should be doing, but this is an instance 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 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 of 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 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 a developer, 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 long 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 into 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. They're there already. They're 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, SameSite Laxbydefault and network cookie, SameSite. None requires secure. So that's how we do it in Firefox. And I'm going to explain both of those in just 1 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 chromeflags, 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 site by default. Cookies that's saying, look, any cookies that come down, I want you to automatically set same site to be Lax. All right? So it's going to set it if the developer didn't do it, the browser is going to do it for you. All right? 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 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 same site 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, hey, you know what? I don't care about same site. 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 lacks 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 that was like, ten 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 happen with the Http only 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 Http, so I need to turn the secure flag off, then by default, the browser is just going to say, you know what, I'm not going to transmit this unless it's over a secure channel and leave that up to the application to turn that off. 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 and 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 side equal to none, but you have to set the cookie to also be secure. But one thing I wanted 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 default and secure by default and then let 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, like Identity Server with net Core automatically sets 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 writing out there saying, hey, look, I had this issue. 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, this is 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 why that is. So make sure we spread this around, make sure everybody understands what same site is, what it's used for, understand 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 Net Core that they are updating something that kind of coincides with this. So you can actually have instead of same site Lax or same site Strict, 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's something that's going to be coming down and is going to be on by default in some of the browsers, which could cause some issues. So that's one of the reasons why I really want to talk about this. Like, one, I love the fact that we're chopping down here at the attack surface, really, of CSRF, but two, 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 SameSite lax and see how that goes. Make sure the site is working as you expect it, all that stuff. Because if it doesn't work as you expect it and 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. So if you have questions about that, looking for more information, anything like that, feel free to reach out. James@developsack.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, 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, stuff's not working and you're scrambling, trying to figure out what the heck is going on. This is the type of stuff that, while it 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 there are 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 at developsec or check out our website@www.developsec.com.