1
00:00:02,009 --> 00:00:03,260
Now in the next lecture,

2
00:00:03,260 --> 00:00:08,070
we'll dive into an effective defense against CSRF attacks.

3
00:00:08,070 --> 00:00:09,180
In this lecture,

4
00:00:09,180 --> 00:00:13,820
I want to dive into a half-effective defense.

5
00:00:13,820 --> 00:00:16,620
And that would be SameSite cookies.

6
00:00:16,620 --> 00:00:20,790
In the last lecture, I showed you that one attack pattern

7
00:00:20,790 --> 00:00:25,790
for a CSRF attacks is that we prepare a malicious website

8
00:00:26,210 --> 00:00:28,560
where we have our prepared form

9
00:00:28,560 --> 00:00:32,159
with our own values in those hidden input fields,

10
00:00:32,159 --> 00:00:34,953
which would be sent to the correct website.

11
00:00:35,820 --> 00:00:37,370
Now there I mentioned that

12
00:00:37,370 --> 00:00:40,550
cookies would be attached to that outgoing request,

13
00:00:40,550 --> 00:00:44,920
even if that request is sent from our malicious site.

14
00:00:44,920 --> 00:00:48,353
So sent whilst we were on that malicious site.

15
00:00:49,290 --> 00:00:53,023
And that is correct, at least in some browsers.

16
00:00:53,870 --> 00:00:58,720
Modern browsers have a feature called "SameSite cookies",

17
00:00:58,720 --> 00:01:02,270
and you can check out the MDN article on SameSite cookies

18
00:01:02,270 --> 00:01:04,163
if you want to learn all about them.

19
00:01:05,220 --> 00:01:08,680
In the end, it's a cookie configuration

20
00:01:08,680 --> 00:01:11,180
that can be set on the server side

21
00:01:11,180 --> 00:01:15,010
where browsers also assume certain default values

22
00:01:15,010 --> 00:01:18,320
if it was not explicitly configured.

23
00:01:18,320 --> 00:01:19,330
And for example,

24
00:01:19,330 --> 00:01:24,330
Chrome uses "lax" as a default configuration.

25
00:01:24,490 --> 00:01:27,000
Now I don't want to dive super deep into

26
00:01:27,000 --> 00:01:30,870
this cookie configuration, but what lax means in the end

27
00:01:30,870 --> 00:01:35,540
is that, yes, cookies can be attached to requests that

28
00:01:35,540 --> 00:01:37,240
come from a different site,

29
00:01:37,240 --> 00:01:41,780
but only if you visited that site from the main site.

30
00:01:41,780 --> 00:01:44,150
So if you clicked on some link in an email,

31
00:01:44,150 --> 00:01:47,900
then cookies would not be attached to the outgoing request,

32
00:01:47,900 --> 00:01:50,150
and therefore the attack pattern I showed you

33
00:01:50,150 --> 00:01:52,940
in the last lecture wouldn't work.

34
00:01:52,940 --> 00:01:56,170
But, there are a couple of restrictions and things

35
00:01:56,170 --> 00:01:57,420
to keep in mind.

36
00:01:57,420 --> 00:01:59,580
For one, if you're on local host,

37
00:01:59,580 --> 00:02:01,600
this is all disabled.

38
00:02:01,600 --> 00:02:03,630
But that doesn't matter too much because

39
00:02:03,630 --> 00:02:05,630
that's only on your local machine,

40
00:02:05,630 --> 00:02:07,980
and not a realistic use case.

41
00:02:07,980 --> 00:02:11,070
So you can only hack yourselves there.

42
00:02:11,070 --> 00:02:13,980
But in addition, here in this MDN article,

43
00:02:13,980 --> 00:02:16,910
which you'll find if you search for SameSite cookies,

44
00:02:16,910 --> 00:02:17,810
At the very bottom,

45
00:02:17,810 --> 00:02:20,350
you'll find a table with more information

46
00:02:20,350 --> 00:02:22,460
about browser support.

47
00:02:22,460 --> 00:02:26,680
And you can learn which browsers support which settings,

48
00:02:26,680 --> 00:02:31,100
and which browsers have this lax setting as a default.

49
00:02:31,100 --> 00:02:33,400
And at the point of time I'm recording this,

50
00:02:33,400 --> 00:02:34,233
for example,

51
00:02:34,233 --> 00:02:37,310
Firefox does not have that as a default.

52
00:02:37,310 --> 00:02:41,010
Safari also doesn't have it as a default.

53
00:02:41,010 --> 00:02:44,570
That means if your visitors are using these browsers

54
00:02:44,570 --> 00:02:45,980
instead of Chrome,

55
00:02:45,980 --> 00:02:50,190
they would be vulnerable to the attack pattern I showed you.

56
00:02:50,190 --> 00:02:52,320
And you probably don't want to throw

57
00:02:52,320 --> 00:02:54,200
these users under the bus.

58
00:02:54,200 --> 00:02:58,520
So that's why the SameSite cookie setting can help,

59
00:02:58,520 --> 00:03:02,810
but still won't be a fully sufficient protection mechanism.

60
00:03:02,810 --> 00:03:05,190
Internet Explorer users, for example, are

61
00:03:05,190 --> 00:03:08,170
entirely left out because data doesn't support

62
00:03:08,170 --> 00:03:10,210
this SameSite setting at all,

63
00:03:10,210 --> 00:03:13,500
even if you would configure your cookies explicitly

64
00:03:13,500 --> 00:03:16,600
to set this in your server side code.

65
00:03:16,600 --> 00:03:20,950
There, you can set the SameSite and set it to lax,

66
00:03:20,950 --> 00:03:22,730
non or strict.

67
00:03:22,730 --> 00:03:24,290
And if you set it to lax,

68
00:03:24,290 --> 00:03:27,830
you then enable lax for all the browsers that's supported,

69
00:03:27,830 --> 00:03:31,800
even the browsers that don't use it as a default anyways.

70
00:03:31,800 --> 00:03:32,633
So with that,

71
00:03:32,633 --> 00:03:36,780
Firefox and Safari would now also use the lax setting

72
00:03:36,780 --> 00:03:39,050
and hence you would have protection against

73
00:03:39,050 --> 00:03:40,690
the patterns shown before,

74
00:03:40,690 --> 00:03:44,490
unless users visited the malicious site with a link

75
00:03:44,490 --> 00:03:48,520
that's on your site, which of course is unlikely.

76
00:03:48,520 --> 00:03:51,960
Still, Internet Explorers would be left out here,

77
00:03:51,960 --> 00:03:55,120
and you do have to set it explicitly.

78
00:03:55,120 --> 00:03:57,330
It's also worth noting that in general,

79
00:03:57,330 --> 00:04:00,520
there are other kinds of CSRF attacks,

80
00:04:00,520 --> 00:04:02,290
and therefore, overall, yes,

81
00:04:02,290 --> 00:04:05,290
you can set this to get some extra protection,

82
00:04:05,290 --> 00:04:09,570
but it won't be full protection for all your users.

83
00:04:09,570 --> 00:04:12,050
It's also worth keeping in mind that

84
00:04:12,050 --> 00:04:13,760
even though it's unlikely,

85
00:04:13,760 --> 00:04:17,959
not all your users are going to use the latest versions of

86
00:04:17,959 --> 00:04:20,123
Chrome, Firefox, and Safari.

87
00:04:20,959 --> 00:04:24,110
So they might be using older versions of these browsers,

88
00:04:24,110 --> 00:04:26,903
and also not have support for that setting.

89
00:04:28,210 --> 00:04:31,410
So even though we're probably then only talking about

90
00:04:31,410 --> 00:04:36,410
a very small user base of one or five percent of users,

91
00:04:36,660 --> 00:04:38,820
that's still too much.

92
00:04:38,820 --> 00:04:43,180
You want to have zero users that are exposed to this attack,

93
00:04:43,180 --> 00:04:47,430
because one user might be enough to compromise your website

94
00:04:47,430 --> 00:04:49,940
and to introduce this problem.

95
00:04:49,940 --> 00:04:52,450
Therefore, this SameSite cookie setting

96
00:04:52,450 --> 00:04:55,580
is absolutely something that's good to have.

97
00:04:55,580 --> 00:04:57,640
It adds extra protection,

98
00:04:57,640 --> 00:04:59,030
but on its own,

99
00:04:59,030 --> 00:05:04,030
it's not enough to protect against CSRF attacks entirely.

100
00:05:04,170 --> 00:05:05,910
Instead, in the next lecture,

101
00:05:05,910 --> 00:05:08,570
we're going to dive into a defense mechanism

102
00:05:08,570 --> 00:05:10,560
that will work for everyone,

103
00:05:10,560 --> 00:05:12,900
and that is the best practice defense

104
00:05:12,900 --> 00:05:15,713
to use against CSRF attacks.