1
00:00:01,940 --> 00:00:03,160
[Autogenerated] Here's an application. I

2
00:00:03,160 --> 00:00:05,440
using another course by me, called

3
00:00:05,440 --> 00:00:07,720
authentication and authorization in a

4
00:00:07,720 --> 00:00:10,890
hospital net core. In the first module of

5
00:00:10,890 --> 00:00:13,890
that course, I'm explaining the basics off

6
00:00:13,890 --> 00:00:16,060
cookie authentication and a speed of net

7
00:00:16,060 --> 00:00:18,740
core. But the principles are the same for

8
00:00:18,740 --> 00:00:19,920
your speed on that foot on their

9
00:00:19,920 --> 00:00:22,900
framework. If you're interested in how

10
00:00:22,900 --> 00:00:25,840
identity cookies work, I suggest to take a

11
00:00:25,840 --> 00:00:30,250
look at that module. The site is using the

12
00:00:30,250 --> 00:00:33,700
built in a Speedo Net identity cookie, but

13
00:00:33,700 --> 00:00:35,900
chances are that you're using a Spiegel

14
00:00:35,900 --> 00:00:39,240
net identity or token based authentication

15
00:00:39,240 --> 00:00:42,300
in yours. It doesn't matter which method

16
00:00:42,300 --> 00:00:45,690
you use if a site requires long in an

17
00:00:45,690 --> 00:00:49,580
identity cookies always used. So let's log

18
00:00:49,580 --> 00:00:54,060
in and take a look at it. The contents is

19
00:00:54,060 --> 00:00:56,790
encrypted, which is always a good idea.

20
00:00:56,790 --> 00:00:59,030
You don't want personal information be

21
00:00:59,030 --> 00:01:02,150
available to anyone, just a sight. But

22
00:01:02,150 --> 00:01:05,970
encryption doesn't help against C. S. R F

23
00:01:05,970 --> 00:01:09,000
attacks, since the cookie is just used to

24
00:01:09,000 --> 00:01:12,170
gain access to the site. The identity

25
00:01:12,170 --> 00:01:15,180
cookie set by a Spiegel net as the same

26
00:01:15,180 --> 00:01:19,210
site attribute, set with Alexe value this

27
00:01:19,210 --> 00:01:22,190
alone most of CSR F attack at it in the

28
00:01:22,190 --> 00:01:25,590
previous clip impossible. How does it

29
00:01:25,590 --> 00:01:28,810
work? The same side Cookie attributes on

30
00:01:28,810 --> 00:01:32,230
the cookie limits the types off requests

31
00:01:32,230 --> 00:01:34,790
that are possible with the cookie. When

32
00:01:34,790 --> 00:01:37,360
it's said too strict, the cookie will not

33
00:01:37,360 --> 00:01:40,700
be sent across side period. That means

34
00:01:40,700 --> 00:01:42,730
that the cookie will only be sent to the

35
00:01:42,730 --> 00:01:45,200
site that is currently shown in the

36
00:01:45,200 --> 00:01:48,150
address bar off the browser if it's set to

37
00:01:48,150 --> 00:01:50,990
LAX like the identity cookie in a spittle,

38
00:01:50,990 --> 00:01:54,540
Met cookies also won't be sent cross site.

39
00:01:54,540 --> 00:01:57,400
But the reason exception? The exception is

40
00:01:57,400 --> 00:02:01,410
forget requests. It sounds like same side

41
00:02:01,410 --> 00:02:03,200
cookies is what we need for the coffee

42
00:02:03,200 --> 00:02:06,480
loyalty site. We add a little bit of goat

43
00:02:06,480 --> 00:02:09,160
in the line where we set the cookie as an

44
00:02:09,160 --> 00:02:11,660
extra parameter, we extend Shi'a ate a

45
00:02:11,660 --> 00:02:14,850
cookie options object. A property off That

46
00:02:14,850 --> 00:02:18,440
object is same site, which is an in um,

47
00:02:18,440 --> 00:02:21,990
let's set it too strict. In normal air

48
00:02:21,990 --> 00:02:24,040
speed of Death Corps, you have to create

49
00:02:24,040 --> 00:02:26,640
an http cookie instance and set the same

50
00:02:26,640 --> 00:02:30,180
side property. After I entered a loyalty

51
00:02:30,180 --> 00:02:32,470
number and examined the cookie, you can

52
00:02:32,470 --> 00:02:36,540
see the same site attribute is set when I

53
00:02:36,540 --> 00:02:39,120
now try to repeat the attack coffee shop

54
00:02:39,120 --> 00:02:41,860
dot com throws an exception. The browser

55
00:02:41,860 --> 00:02:44,880
did post a form to coffee shop dot com,

56
00:02:44,880 --> 00:02:46,960
but it didn't sent the cookie along

57
00:02:46,960 --> 00:02:49,140
because the same site attributes is now

58
00:02:49,140 --> 00:02:52,380
said to strict in the H E mail off the

59
00:02:52,380 --> 00:02:55,510
Attackers website, I've added a link to

60
00:02:55,510 --> 00:02:59,890
the edit favorite page just now. This also

61
00:02:59,890 --> 00:03:02,870
is a cross site request, but it's a get

62
00:03:02,870 --> 00:03:05,490
instead of a post we saw in the form.

63
00:03:05,490 --> 00:03:07,590
After entering the loyalty number again, I

64
00:03:07,590 --> 00:03:10,050
follow the link. As you can see, the

65
00:03:10,050 --> 00:03:13,920
cookie is also no scent. The only way to

66
00:03:13,920 --> 00:03:16,510
make this work is to let the user enter

67
00:03:16,510 --> 00:03:18,760
the loyalty number again, which is

68
00:03:18,760 --> 00:03:20,780
equivalent to the behavior of an

69
00:03:20,780 --> 00:03:22,750
application that is configured to use the

70
00:03:22,750 --> 00:03:25,500
A speed Internet identity cookie. It will

71
00:03:25,500 --> 00:03:28,410
just display the law in page, which might

72
00:03:28,410 --> 00:03:31,070
come across a strange not to mention

73
00:03:31,070 --> 00:03:33,570
irritating. If the user locked into the

74
00:03:33,570 --> 00:03:37,120
same application just before when I said

75
00:03:37,120 --> 00:03:40,630
same site to Lex and try again, the form

76
00:03:40,630 --> 00:03:44,710
post still doesn't work, but when I tried

77
00:03:44,710 --> 00:03:48,290
the link, it does work. Setting same side

78
00:03:48,290 --> 00:03:51,000
to Lex will only send the cookie cross

79
00:03:51,000 --> 00:03:54,170
site if the request is a get request, but

80
00:03:54,170 --> 00:03:58,340
not all get requests as we'll see later.

81
00:03:58,340 --> 00:04:02,210
By the way, besides a get request, hat

82
00:04:02,210 --> 00:04:05,340
options or trace requests are also allowed

83
00:04:05,340 --> 00:04:08,320
in Lex mode. There's another possible

84
00:04:08,320 --> 00:04:10,880
option for the same side attribute. It can

85
00:04:10,880 --> 00:04:14,560
be said to none That seems off because

86
00:04:14,560 --> 00:04:16,560
none would be the same as omitting the

87
00:04:16,560 --> 00:04:19,810
attribute altogether. The option is there

88
00:04:19,810 --> 00:04:22,600
because browsers will default to Delecti

89
00:04:22,600 --> 00:04:25,910
same site cookie mode soon. At the time of

90
00:04:25,910 --> 00:04:28,880
writing, only chrome supports it, but more

91
00:04:28,880 --> 00:04:31,910
will follow. This means that when you omit

92
00:04:31,910 --> 00:04:34,020
the same site attributes when setting a

93
00:04:34,020 --> 00:04:36,730
cookie, the browser will give it a same

94
00:04:36,730 --> 00:04:39,120
site attributes with the value lacks

95
00:04:39,120 --> 00:04:41,790
anyway. So if you don't want same site

96
00:04:41,790 --> 00:04:44,380
cookies at all, you have to set same site

97
00:04:44,380 --> 00:04:47,910
to none. Browsers with this new behavior I

98
00:04:47,910 --> 00:04:50,990
talked about will only allow setting same

99
00:04:50,990 --> 00:04:54,160
side to none. When the cookie also has the

100
00:04:54,160 --> 00:04:58,090
secure flag, that flag will only transmit

101
00:04:58,090 --> 00:05:01,240
the cookie over https. When a connection

102
00:05:01,240 --> 00:05:03,750
is used that is not secure, it won't

103
00:05:03,750 --> 00:05:08,170
descend at all. The same site mode in um

104
00:05:08,170 --> 00:05:10,720
also has none, and you can set the secure

105
00:05:10,720 --> 00:05:13,030
flag by using another property off the

106
00:05:13,030 --> 00:05:15,560
cookie options object Another cookie

107
00:05:15,560 --> 00:05:19,040
option that mitigates an attack vector.

108
00:05:19,040 --> 00:05:22,210
It's 80 to be. Only this will make sure

109
00:05:22,210 --> 00:05:24,050
the cookie is not accessible from

110
00:05:24,050 --> 00:05:27,130
JavaScript. If you do not need to access

111
00:05:27,130 --> 00:05:30,210
the value from JavaScript, I would suggest

112
00:05:30,210 --> 00:05:34,760
to turn his own, too. So C S R F seems to

113
00:05:34,760 --> 00:05:37,840
be sold by same side cookies. Well,

114
00:05:37,840 --> 00:05:41,000
almost. We're not home free because the

115
00:05:41,000 --> 00:05:44,830
most commonly use setting is lax. Lex

116
00:05:44,830 --> 00:05:48,080
still makes, sees a ref attacks possible.

117
00:05:48,080 --> 00:05:51,200
I'll talk about that in a later clip, but

118
00:05:51,200 --> 00:05:53,880
in general, same site cookies are a great

119
00:05:53,880 --> 00:05:57,870
solution to see is a ref. The downside is

120
00:05:57,870 --> 00:06:01,180
that it just works on your browser's To

121
00:06:01,180 --> 00:06:03,570
see which browser versions are supported.

122
00:06:03,570 --> 00:06:07,030
Take a look at this u R l You also have to

123
00:06:07,030 --> 00:06:10,730
use dot net framework 472 or higher or

124
00:06:10,730 --> 00:06:12,710
don't net court to one or higher, for

125
00:06:12,710 --> 00:06:15,580
you're a speed on that application. What

126
00:06:15,580 --> 00:06:17,880
if you and your users don't have the

127
00:06:17,880 --> 00:06:25,000
latest and the greatest? Then there's not a solution, and that's up next

