Now in the next lecture,
we'll dive into an effective defense against CSRF attacks.
In this lecture,
I want to dive into a half-effective defense.
And that would be SameSite cookies.
In the last lecture, I showed you that one attack pattern
for a CSRF attacks is that we prepare a malicious website
where we have our prepared form
with our own values in those hidden input fields,
which would be sent to the correct website.
Now there I mentioned that
cookies would be attached to that outgoing request,
even if that request is sent from our malicious site.
So sent whilst we were on that malicious site.
And that is correct, at least in some browsers.
Modern browsers have a feature called "SameSite cookies",
and you can check out the MDN article on SameSite cookies
if you want to learn all about them.
In the end, it's a cookie configuration
that can be set on the server side
where browsers also assume certain default values
if it was not explicitly configured.
And for example,
Chrome uses "lax" as a default configuration.
Now I don't want to dive super deep into
this cookie configuration, but what lax means in the end
is that, yes, cookies can be attached to requests that
come from a different site,
but only if you visited that site from the main site.
So if you clicked on some link in an email,
then cookies would not be attached to the outgoing request,
and therefore the attack pattern I showed you
in the last lecture wouldn't work.
But, there are a couple of restrictions and things
to keep in mind.
For one, if you're on local host,
this is all disabled.
But that doesn't matter too much because
that's only on your local machine,
and not a realistic use case.
So you can only hack yourselves there.
But in addition, here in this MDN article,
which you'll find if you search for SameSite cookies,
At the very bottom,
you'll find a table with more information
about browser support.
And you can learn which browsers support which settings,
and which browsers have this lax setting as a default.
And at the point of time I'm recording this,
for example,
Firefox does not have that as a default.
Safari also doesn't have it as a default.
That means if your visitors are using these browsers
instead of Chrome,
they would be vulnerable to the attack pattern I showed you.
And you probably don't want to throw
these users under the bus.
So that's why the SameSite cookie setting can help,
but still won't be a fully sufficient protection mechanism.
Internet Explorer users, for example, are
entirely left out because data doesn't support
this SameSite setting at all,
even if you would configure your cookies explicitly
to set this in your server side code.
There, you can set the SameSite and set it to lax,
non or strict.
And if you set it to lax,
you then enable lax for all the browsers that's supported,
even the browsers that don't use it as a default anyways.
So with that,
Firefox and Safari would now also use the lax setting
and hence you would have protection against
the patterns shown before,
unless users visited the malicious site with a link
that's on your site, which of course is unlikely.
Still, Internet Explorers would be left out here,
and you do have to set it explicitly.
It's also worth noting that in general,
there are other kinds of CSRF attacks,
and therefore, overall, yes,
you can set this to get some extra protection,
but it won't be full protection for all your users.
It's also worth keeping in mind that
even though it's unlikely,
not all your users are going to use the latest versions of
Chrome, Firefox, and Safari.
So they might be using older versions of these browsers,
and also not have support for that setting.
So even though we're probably then only talking about
a very small user base of one or five percent of users,
that's still too much.
You want to have zero users that are exposed to this attack,
because one user might be enough to compromise your website
and to introduce this problem.
Therefore, this SameSite cookie setting
is absolutely something that's good to have.
It adds extra protection,
but on its own,
it's not enough to protect against CSRF attacks entirely.
Instead, in the next lecture,
we're going to dive into a defense mechanism
that will work for everyone,
and that is the best practice defense
to use against CSRF attacks.