Lax versus Strict

[00:00:00]
>> Steve Kinney: And so I kind of alluded to before, Lax is probably the best balance because you can send links and stuff along those lines. But strict, obviously, if you can get away with it, sure, yeah, do that. But you probably can't for a lot of cases. But if you're working on developer tool, I don't know, some Someone sends you a link, maybe it's fair to make you log in again, but if you are a social media bar store, that's not okay?

[00:00:25]
And so it all depends on the use case. And this is that balance between the trade offs, between UX and security sometimes, which is if your site is inhospitable to use. You don't really need to worry about security that much because you only got no users, generally speaking, as far as we're concerned.

[00:00:39]
This is the law of the land. But I worry about, particularly people who have older machines that maybe don't get updates. And so you're not totally out of the woods there, but generally speaking, you can hope but you ideally have analytics on the browser usage. If you see 100% that everything's above this, then sure, you can hope for the same site lax as the default.

[00:01:08]
You can also set it as Lax when you set the cookie, or strict as well. But if it's a giant microservice architecture, stuff is going around, you have this whole legacy thing, and maybe it's It's hard to do, to set it, but generally speaking, this is the kind of timeline there.

[00:01:24]
There's one exception which people have taken advantage of, which we'll call the two-minute rule, which is effectively OAuth, when there's that kind of back and forth dance between different origins to set the cooking and stuff along those lines. If you're not setting explicitly, there's a two-minute window where it's not such that lack security can be none in that case.

[00:01:48]
But that's a very tiny window for an attack, especially when we're talking about CSRF, which means in the time that you've just logged in, you would then need to make it to the nefarious site, right? That's not to ruin the end of the first Star Wars movie, but it is unlikely that charge is getting into the Death Star.

[00:02:08]
But yeah, to be clear, if I needed to further hone my point of you should still do the protections we're gonna see, here's an appeal to that point. Cool, so we'll do this in a second, same site, cookies. We will definitely again, Lax is the default, but it doesn't hurt to set it.

[00:02:29]
And then we saw before, which is if the issue is that we need some amount of unpredictability, we can just put unpredictable. Ability into our form, that you need to know some special thing that only the user would know. Because again, they're not in your app, they're somewhere else.

[00:02:49]
If theoretically, don't have any kind of weird token that you made. Kind of when we saw the signing the cookie before, they don't have that available. You can can leak it and there are easy ways to do that which you'll see as well. But generally speaking, some of these will work.

[00:03:08]
But we're gonna focus on the first one. The referrer-based validation is tracking the referrer header, but you can spoof that it's not hard.