WEBVTT

1
00:00:00.040 --> 00:00:03.160
<v Speaker 1>Welcome back to the deep dive. Today. We're really getting

2
00:00:03.160 --> 00:00:05.960
<v Speaker 1>into some source material you shared with us. It's excerpts

3
00:00:06.040 --> 00:00:09.400
<v Speaker 1>from Advanced ASP dot net Core three security.

4
00:00:09.640 --> 00:00:13.000
<v Speaker 2>That's right, and our mission really is to unpack this,

5
00:00:13.359 --> 00:00:15.119
<v Speaker 2>pull out the key stuff you need to know about

6
00:00:15.119 --> 00:00:18.640
<v Speaker 2>web app security, especially in that ASP dot net core

7
00:00:18.719 --> 00:00:19.640
<v Speaker 2>three context.

8
00:00:19.719 --> 00:00:22.280
<v Speaker 1>Yeah, think of it as a focused tour. We want

9
00:00:22.280 --> 00:00:26.440
<v Speaker 1>to get you the crucial concepts, common attacks, practical defenses,

10
00:00:26.920 --> 00:00:29.120
<v Speaker 1>all straight from this material exactly.

11
00:00:29.160 --> 00:00:31.760
<v Speaker 2>We're aiming for those moments where it clicks, maybe some

12
00:00:31.800 --> 00:00:35.479
<v Speaker 2>surprising bits along the way that really stick.

13
00:00:35.679 --> 00:00:37.799
<v Speaker 1>We'll cover quite a bit starting with the basics what

14
00:00:37.880 --> 00:00:41.359
<v Speaker 1>is security online? Then look at how attacks happen, common

15
00:00:41.359 --> 00:00:42.880
<v Speaker 1>ones like SEQL injection.

16
00:00:42.640 --> 00:00:46.439
<v Speaker 2>EXSS, and specifically how aspnt core three deals with them.

17
00:00:46.840 --> 00:00:52.200
<v Speaker 2>Sometimes the default behavior is well interesting. We'll definitely cover authentication, authorization, testing,

18
00:00:52.640 --> 00:00:53.479
<v Speaker 2>a whole life cycle.

19
00:00:53.520 --> 00:00:55.920
<v Speaker 1>Really, the goal isn't just a list, right, it's the

20
00:00:55.960 --> 00:00:59.079
<v Speaker 1>why why these things matter, so you can build systems

21
00:00:59.119 --> 00:01:00.479
<v Speaker 1>that are genuinely solid.

22
00:01:00.600 --> 00:01:03.200
<v Speaker 2>Absolutely, it's about context, not just checklists.

23
00:01:03.359 --> 00:01:05.400
<v Speaker 1>Okay, so let's kick things off right at the beginning.

24
00:01:05.799 --> 00:01:09.599
<v Speaker 1>Security for websites applications. What are we actually trying to

25
00:01:09.640 --> 00:01:14.640
<v Speaker 1>protect the source brings up the classic model, the CIA triad.

26
00:01:15.040 --> 00:01:20.519
<v Speaker 2>Ah yes, CIA good old confidentiality, integrity and availability.

27
00:01:20.879 --> 00:01:22.280
<v Speaker 3>Simple concepts, but.

28
00:01:22.439 --> 00:01:25.799
<v Speaker 1>Fundamental confidentiality first, keeping things secret.

29
00:01:25.519 --> 00:01:28.439
<v Speaker 2>Pretty much Yeah, making sure only the right people or

30
00:01:28.480 --> 00:01:32.599
<v Speaker 2>systems can access sensitive data, you know, like customer info,

31
00:01:32.760 --> 00:01:34.079
<v Speaker 2>private messages.

32
00:01:33.599 --> 00:01:36.799
<v Speaker 1>That sort of thing. So stopping unauthorized peaking, got it?

33
00:01:36.879 --> 00:01:37.879
<v Speaker 1>And integrity.

34
00:01:37.959 --> 00:01:41.040
<v Speaker 2>Integrity is about trust, Trust that the data hasn't been

35
00:01:41.079 --> 00:01:43.519
<v Speaker 2>messed with, that it's accurate, whether it's sitting in a

36
00:01:43.599 --> 00:01:45.400
<v Speaker 2>database or flying across the network.

37
00:01:45.519 --> 00:01:48.079
<v Speaker 1>Makes sense, like you wouldn't want someone changing order details

38
00:01:48.120 --> 00:01:49.120
<v Speaker 1>mid process.

39
00:01:48.840 --> 00:01:52.959
<v Speaker 2>Exactly or subtly altering content on a website without anyone noticing.

40
00:01:53.159 --> 00:01:54.000
<v Speaker 3>You need to know what's.

41
00:01:53.879 --> 00:01:56.239
<v Speaker 1>Reliable and the last one. Availability.

42
00:01:56.359 --> 00:01:59.400
<v Speaker 2>Availability just means the systems up and running when legitimate

43
00:01:59.480 --> 00:02:02.879
<v Speaker 2>users need it. Think DIDOS attacks trying to knock a

44
00:02:02.920 --> 00:02:05.519
<v Speaker 2>site offline. That's an attack on availability.

45
00:02:05.840 --> 00:02:07.959
<v Speaker 1>Though the source makes a fair point, doesn't it that?

46
00:02:08.000 --> 00:02:11.280
<v Speaker 1>For web developers, our main focus often ends up being

47
00:02:11.280 --> 00:02:16.479
<v Speaker 1>more on confidentiality and integrity. Availability sometimes falls more to

48
00:02:17.360 --> 00:02:18.599
<v Speaker 1>like infrastructure teams.

49
00:02:18.800 --> 00:02:22.560
<v Speaker 2>Often, Yeah, it's a reasonable distinction in practice. Now, who

50
00:02:22.560 --> 00:02:26.120
<v Speaker 2>are we defending against the term hacker gets thrown around

51
00:02:26.159 --> 00:02:29.439
<v Speaker 2>a lot, right. The book outlines a typical attack flow

52
00:02:29.879 --> 00:02:31.199
<v Speaker 2>starts with reconnaissance, just.

53
00:02:31.159 --> 00:02:33.840
<v Speaker 1>Gathering info, scoping things out, YEP.

54
00:02:33.800 --> 00:02:39.400
<v Speaker 2>Finding vulnerabilities, understanding the technology, looking for weak points, all

55
00:02:39.439 --> 00:02:40.680
<v Speaker 2>the homework before the.

56
00:02:40.680 --> 00:02:43.199
<v Speaker 1>Actual attempt, and after recon.

57
00:02:42.960 --> 00:02:43.960
<v Speaker 3>Then comes penetrate.

58
00:02:44.000 --> 00:02:46.680
<v Speaker 2>That's the initial break in exploiting a weakness found during

59
00:02:46.680 --> 00:02:48.240
<v Speaker 2>recon to get that first foothold.

60
00:02:48.280 --> 00:02:50.280
<v Speaker 1>And they don't just stop there, presumably no.

61
00:02:50.240 --> 00:02:54.840
<v Speaker 2>Way next is often hide evidence, covering their tracks, maybe

62
00:02:54.879 --> 00:02:57.280
<v Speaker 2>setting up persistent so they can stay in longer without

63
00:02:57.280 --> 00:02:57.960
<v Speaker 2>being detected.

64
00:02:58.159 --> 00:03:01.000
<v Speaker 1>Makes sense, want to stick around and it's worth remembering.

65
00:03:01.159 --> 00:03:04.240
<v Speaker 2>Like the book says, it's not always super technical exploits,

66
00:03:04.520 --> 00:03:07.479
<v Speaker 2>phishing emails, maybe even a disgruntled employee.

67
00:03:07.560 --> 00:03:08.840
<v Speaker 3>Those are common ways in two.

68
00:03:09.039 --> 00:03:12.840
<v Speaker 1>Yeah, the human element. Okay, some key terms the source clarifies. First,

69
00:03:13.360 --> 00:03:15.560
<v Speaker 1>attack surface, what's the deal there?

70
00:03:15.599 --> 00:03:19.479
<v Speaker 2>Your attack surface is basically while all the different points

71
00:03:19.479 --> 00:03:22.080
<v Speaker 2>where an attacker could possibly try to interact with your system,

72
00:03:22.159 --> 00:03:26.439
<v Speaker 2>think log in forms, APIs, file uploads, anywhere input.

73
00:03:26.159 --> 00:03:28.879
<v Speaker 1>Is accepted, and the general idea is to make that smaller, right,

74
00:03:29.240 --> 00:03:30.639
<v Speaker 1>less places to attack.

75
00:03:30.479 --> 00:03:34.599
<v Speaker 2>Usually yes, minimize the surface, but there's this interesting nuance

76
00:03:34.639 --> 00:03:38.199
<v Speaker 2>mentioned sometimes increasing the number of attack points, like maybe

77
00:03:38.199 --> 00:03:40.919
<v Speaker 2>splitting a sensitive function into its own separate API.

78
00:03:41.199 --> 00:03:42.479
<v Speaker 1>Wait, increasing it helps.

79
00:03:42.840 --> 00:03:45.639
<v Speaker 2>How it sounds weird, I know, but think about the

80
00:03:45.639 --> 00:03:49.319
<v Speaker 2>impact if that separate sensitive API gets breached. Maybe the

81
00:03:49.400 --> 00:03:52.360
<v Speaker 2>damage is contained just to that sensitive data. If it

82
00:03:52.400 --> 00:03:55.159
<v Speaker 2>was all part of one big application, the breach might

83
00:03:55.199 --> 00:03:59.719
<v Speaker 2>expose everything, so larger surface potentially smaller blast radius.

84
00:04:00.199 --> 00:04:05.280
<v Speaker 1>Okay, that's a counterintuitive point. Interesting. Next term security by obscurity.

85
00:04:05.400 --> 00:04:08.719
<v Speaker 2>Ah, this one the idea you can secure something just

86
00:04:08.759 --> 00:04:11.599
<v Speaker 2>by hiding it well, like using a weird port number

87
00:04:11.719 --> 00:04:14.919
<v Speaker 2>or a secret URL. And the verdict is for web apps,

88
00:04:15.000 --> 00:04:18.000
<v Speaker 2>forget it. It's just not a reliable strategy. The web

89
00:04:18.040 --> 00:04:20.319
<v Speaker 2>is designed to be found, and scanners are really good

90
00:04:20.319 --> 00:04:23.040
<v Speaker 2>at finding things no matter how obscure you think you've

91
00:04:23.040 --> 00:04:25.639
<v Speaker 2>made them. Hiding isn't securing.

92
00:04:25.600 --> 00:04:28.560
<v Speaker 1>Right, Okay. A core theme that comes up again and

93
00:04:28.600 --> 00:04:32.720
<v Speaker 1>again is this balance. Security isn't purely technical.

94
00:04:32.879 --> 00:04:36.639
<v Speaker 2>Absolutely, it's a business decision fundamentally.

95
00:04:36.079 --> 00:04:38.600
<v Speaker 1>Like that analogy in the source. Yeah, you don't spend

96
00:04:38.639 --> 00:04:41.439
<v Speaker 1>one hundred bucks to protect a twenty dollars bill exactly.

97
00:04:41.720 --> 00:04:44.319
<v Speaker 2>The effort has to match the value of what you're protecting.

98
00:04:44.639 --> 00:04:51.519
<v Speaker 2>Protecting say PII personally identifiable information or PHI personal health

99
00:04:51.519 --> 00:04:55.639
<v Speaker 2>information that demands way more security effort than I don't know,

100
00:04:55.720 --> 00:04:57.519
<v Speaker 2>a simple brochure website.

101
00:04:57.600 --> 00:04:59.560
<v Speaker 1>Higher stakes, more protection, right.

102
00:05:00.040 --> 00:05:03.839
<v Speaker 2>Leads directly into that classic tension between security and user

103
00:05:03.879 --> 00:05:05.319
<v Speaker 2>experience or UX.

104
00:05:05.399 --> 00:05:07.879
<v Speaker 1>Yeah, the more secure often the more annoying for the user. Right,

105
00:05:08.040 --> 00:05:08.920
<v Speaker 1>more steps, more.

106
00:05:08.800 --> 00:05:11.959
<v Speaker 2>Friction, totally finding that sweet spot is key. You expect

107
00:05:12.160 --> 00:05:15.160
<v Speaker 2>MFA and maybe some extra checks logging into your bank.

108
00:05:15.240 --> 00:05:17.319
<v Speaker 2>You'd be pretty annoyed if a simple form made you

109
00:05:17.399 --> 00:05:20.160
<v Speaker 2>jump through those same hoops. Context is everything.

110
00:05:20.439 --> 00:05:23.759
<v Speaker 1>Okay, foundation's laid. Let's shift into some core tech stuff.

111
00:05:23.800 --> 00:05:30.759
<v Speaker 1>But through that security lens. Cryptography first, symmetric encryption. What's

112
00:05:30.839 --> 00:05:32.000
<v Speaker 1>the key takeaway?

113
00:05:32.079 --> 00:05:33.680
<v Speaker 3>Symmetric means same key.

114
00:05:34.279 --> 00:05:38.360
<v Speaker 2>One key locks the data, encrypts plaintext to ciphertext, the

115
00:05:38.399 --> 00:05:40.959
<v Speaker 2>same key unlocks it decrypts back to plaintext.

116
00:05:41.079 --> 00:05:43.040
<v Speaker 1>And the standard now is AES YEP.

117
00:05:42.959 --> 00:05:46.160
<v Speaker 2>AES based on Rhindale. It's a block cipher. The source

118
00:05:46.199 --> 00:05:49.480
<v Speaker 2>mentions things like ryandale create encryptor just to give the concept.

119
00:05:49.600 --> 00:05:53.000
<v Speaker 1>And there's something called an initialization vector in OIV right.

120
00:05:52.839 --> 00:05:56.720
<v Speaker 2>And IV is basically random data mixed in during encryption.

121
00:05:57.000 --> 00:05:59.040
<v Speaker 2>Its main job is to make sure encrypting the same

122
00:05:59.120 --> 00:06:02.000
<v Speaker 2>data with the same key D produces different results each time.

123
00:06:02.160 --> 00:06:06.160
<v Speaker 1>Ah, so attackers can't spot patterns easily, and it's safe

124
00:06:06.199 --> 00:06:08.120
<v Speaker 1>to store the IV with the encrypted data.

125
00:06:08.199 --> 00:06:11.079
<v Speaker 2>Generally, yes, the security comes from the key, not the

126
00:06:11.120 --> 00:06:12.199
<v Speaker 2>IV's secrecy.

127
00:06:12.279 --> 00:06:15.199
<v Speaker 1>Okay, that's symmetric. Hashing is different, though totally different.

128
00:06:15.240 --> 00:06:16.360
<v Speaker 3>Hashing is a one way street.

129
00:06:16.439 --> 00:06:18.519
<v Speaker 2>You put data in, you get a fixed size string

130
00:06:18.639 --> 00:06:22.000
<v Speaker 2>the hash out, but you can't realistically go backwards from

131
00:06:22.040 --> 00:06:23.519
<v Speaker 2>the hash to the original.

132
00:06:23.279 --> 00:06:24.959
<v Speaker 1>Data, and its main use is in security.

133
00:06:25.160 --> 00:06:29.720
<v Speaker 2>Two big ones highlighted checking integrity, making sure data hasn't changed.

134
00:06:30.120 --> 00:06:34.600
<v Speaker 2>You hash it, store the hash later, rehash it, compare

135
00:06:35.040 --> 00:06:38.399
<v Speaker 2>if they match it's unchanged. Makes sense, And the other

136
00:06:38.639 --> 00:06:40.199
<v Speaker 2>secure password storage.

137
00:06:40.199 --> 00:06:41.000
<v Speaker 3>This is huge.

138
00:06:41.279 --> 00:06:44.120
<v Speaker 2>Instead of storing passwords directly, which is a disaster waiting

139
00:06:44.160 --> 00:06:46.519
<v Speaker 2>to happen if you get breached, you store a hash

140
00:06:46.560 --> 00:06:47.399
<v Speaker 2>of the password.

141
00:06:47.720 --> 00:06:49.800
<v Speaker 1>So when I log in, you hash what I type

142
00:06:49.800 --> 00:06:51.879
<v Speaker 1>and compare it to the stored hash exactly.

143
00:06:52.000 --> 00:06:54.920
<v Speaker 2>If the hash is match, you entered the right password,

144
00:06:55.040 --> 00:06:57.120
<v Speaker 2>but the original password was never stored.

145
00:06:57.319 --> 00:07:00.000
<v Speaker 1>Smart what about hash collisions cou'd bad.

146
00:07:00.439 --> 00:07:02.959
<v Speaker 2>It can be a collision is when two different inputs

147
00:07:03.000 --> 00:07:06.079
<v Speaker 2>happen to produce the exact same hash. If people can

148
00:07:06.120 --> 00:07:09.319
<v Speaker 2>find collisions easily for an algorithm, it weakens it for

149
00:07:09.399 --> 00:07:12.639
<v Speaker 2>things like digital signatures and it gets deprecated.

150
00:07:12.720 --> 00:07:14.040
<v Speaker 3>Think MD five right.

151
00:07:14.120 --> 00:07:17.199
<v Speaker 1>And for password hashing, salts are absolutely.

152
00:07:16.680 --> 00:07:18.160
<v Speaker 3>Critical, oh completely vital.

153
00:07:18.160 --> 00:07:21.199
<v Speaker 2>Assault is just unique random data that you add to

154
00:07:21.240 --> 00:07:23.959
<v Speaker 2>the password before you hash it. Each user gets their

155
00:07:24.000 --> 00:07:26.600
<v Speaker 2>own unique salt stored alongside their password hash.

156
00:07:26.639 --> 00:07:27.920
<v Speaker 1>Why what does that randomness do?

157
00:07:28.319 --> 00:07:31.879
<v Speaker 2>It kills Rainbow table attacks. Rainbow tables are these huge,

158
00:07:32.000 --> 00:07:35.920
<v Speaker 2>pre calculated lists of hashes for common passwords. If you

159
00:07:35.959 --> 00:07:39.160
<v Speaker 2>don't use salts, an attacker steals your database, looks up

160
00:07:39.160 --> 00:07:41.040
<v Speaker 2>the hashes in their table, and boom, they have the

161
00:07:41.040 --> 00:07:43.639
<v Speaker 2>passwords for common ones instantly, but with salts.

162
00:07:43.680 --> 00:07:46.360
<v Speaker 1>If my password is password one T three with SALTA

163
00:07:46.439 --> 00:07:49.519
<v Speaker 1>and yours is also password one two three, but with salty.

164
00:07:49.439 --> 00:07:53.040
<v Speaker 2>The resulting hashes will be totally different. Hashing salted plus

165
00:07:53.040 --> 00:07:55.600
<v Speaker 2>password one two three is different from hashing salt B

166
00:07:55.680 --> 00:07:58.800
<v Speaker 2>plus password one two three. The attacker's pre computed table

167
00:07:58.879 --> 00:08:02.399
<v Speaker 2>is useless. They need a separate table for every possible salt,

168
00:08:02.439 --> 00:08:05.600
<v Speaker 2>which just isn't feasible. The source shows a table demonstrating

169
00:08:05.680 --> 00:08:06.240
<v Speaker 2>this perfectly.

170
00:08:06.319 --> 00:08:09.279
<v Speaker 1>Okay, got it, salts defeat pre computation. What are the

171
00:08:09.319 --> 00:08:11.959
<v Speaker 1>hashing algorithms themselves? SAHA one is a no go.

172
00:08:12.160 --> 00:08:15.160
<v Speaker 2>Yeah, SAHA one is considered broken. SAGA two family like

173
00:08:15.319 --> 00:08:18.199
<v Speaker 2>SAHA two, SAHA five, twelve are the current standards and

174
00:08:18.240 --> 00:08:19.639
<v Speaker 2>dot net core for general hashing.

175
00:08:19.720 --> 00:08:21.040
<v Speaker 3>But for passwords.

176
00:08:20.519 --> 00:08:21.920
<v Speaker 1>Specifically, you want something different.

177
00:08:21.959 --> 00:08:24.160
<v Speaker 2>Yeah, you actually want algorithms designed to be slow and

178
00:08:24.199 --> 00:08:27.000
<v Speaker 2>resource intensive. Things like PBKDF two be.

179
00:08:27.000 --> 00:08:29.959
<v Speaker 1>Crypt script slow. Why slow makes.

180
00:08:29.759 --> 00:08:32.840
<v Speaker 2>It much harder for attackers to brute force guest passwords

181
00:08:33.320 --> 00:08:37.200
<v Speaker 2>If each hash calculation takes significant time, trying billions of

182
00:08:37.240 --> 00:08:41.840
<v Speaker 2>combinations becomes incredibly expensive and slow for them. NIST actually

183
00:08:41.879 --> 00:08:44.600
<v Speaker 2>recommends PBKDF two for password hashing.

184
00:08:44.759 --> 00:08:48.039
<v Speaker 1>Okay. Quick mention of asymmetric encryption like RSA.

185
00:08:48.120 --> 00:08:51.519
<v Speaker 2>Asymmetric uses two keys, a public one you can share

186
00:08:51.559 --> 00:08:54.279
<v Speaker 2>and a private one you keep secret. Encrypt with public,

187
00:08:54.440 --> 00:08:58.639
<v Speaker 2>decrypt with private, or sign with private, verify with public.

188
00:08:58.759 --> 00:09:03.600
<v Speaker 2>It's used everywhere like in TLSSSL. The source does mention

189
00:09:03.639 --> 00:09:07.320
<v Speaker 2>a future concern about quantum computers potentially breaking current algorithms

190
00:09:07.360 --> 00:09:10.039
<v Speaker 2>like RSA, but that's more of a long term heads up.

191
00:09:10.080 --> 00:09:14.039
<v Speaker 1>All right, let's pivot to the Web itself connections requests responses,

192
00:09:14.320 --> 00:09:16.960
<v Speaker 1>but with that security had on HTTPS connections.

193
00:09:17.080 --> 00:09:19.720
<v Speaker 2>So when your browser hits an HTTPS site, there's that

194
00:09:19.879 --> 00:09:23.519
<v Speaker 2>SSLTLS handshake. First, it's a complex back and forth using

195
00:09:23.559 --> 00:09:27.039
<v Speaker 2>asymmetric crypto like RSA to verify the server's identity via

196
00:09:27.120 --> 00:09:29.799
<v Speaker 2>certificate and securely agree on a symmetric key.

197
00:09:30.279 --> 00:09:32.519
<v Speaker 1>So asymmetric sets it up, but then they switch to

198
00:09:32.559 --> 00:09:34.840
<v Speaker 1>faster symmetric encryption for the actual data.

199
00:09:34.879 --> 00:09:35.480
<v Speaker 3>Precisely.

200
00:09:35.879 --> 00:09:39.080
<v Speaker 2>The handshake uses random nonsense too to stop replay attacks,

201
00:09:39.480 --> 00:09:42.559
<v Speaker 2>and your browser checks the certificate against trusted authorities.

202
00:09:42.639 --> 00:09:45.480
<v Speaker 1>We also need to get the basics of a request

203
00:09:45.519 --> 00:09:47.840
<v Speaker 1>in response header's body.

204
00:09:48.200 --> 00:09:51.840
<v Speaker 2>Yeah, understanding what's in those is key. Request headers carry

205
00:09:51.879 --> 00:09:55.120
<v Speaker 2>browser info cookie stuff like that. Response heaters tell the

206
00:09:55.120 --> 00:09:58.200
<v Speaker 2>browser what to do. Set cookies give security instructions and

207
00:09:58.240 --> 00:09:59.039
<v Speaker 2>status codes.

208
00:09:59.240 --> 00:10:03.240
<v Speaker 1>Status codes four or four not found, five hundred, server error,

209
00:10:03.440 --> 00:10:06.759
<v Speaker 1>four to one, unauthorized, four to three forbidden. They tell

210
00:10:06.799 --> 00:10:07.720
<v Speaker 1>a story they really do.

211
00:10:07.879 --> 00:10:09.879
<v Speaker 2>Four oh one means log in, four to three means

212
00:10:09.919 --> 00:10:12.600
<v Speaker 2>you're logged in, but nope, not allowed. The source notes

213
00:10:12.639 --> 00:10:15.320
<v Speaker 2>a small detail ASP met often uses a three zho

214
00:10:15.320 --> 00:10:17.919
<v Speaker 2>two redirect after a post up when technically a three

215
00:10:18.000 --> 00:10:20.519
<v Speaker 2>oh three sec other might be more correct according to

216
00:10:20.519 --> 00:10:23.600
<v Speaker 2>the HDDC spec minor but details count now.

217
00:10:23.679 --> 00:10:26.919
<v Speaker 1>Security headers these sound important. Server tells a browser to

218
00:10:26.919 --> 00:10:27.360
<v Speaker 1>be more.

219
00:10:27.200 --> 00:10:31.519
<v Speaker 2>Secure exactly and often underutilized hsts. Strict transport security is

220
00:10:31.519 --> 00:10:33.440
<v Speaker 2>a big one. After the first visit, it tells the

221
00:10:33.480 --> 00:10:36.159
<v Speaker 2>browser only connect via HTTPS from now on for a

222
00:10:36.200 --> 00:10:38.919
<v Speaker 2>set period. Max age prevents a text that try to

223
00:10:38.960 --> 00:10:40.799
<v Speaker 2>downgrade you to HTTP, but.

224
00:10:40.799 --> 00:10:44.480
<v Speaker 1>It only works after that first successful HTTPS connection. Right,

225
00:10:44.759 --> 00:10:47.120
<v Speaker 1>you still need the initial redirect from HTTP.

226
00:10:47.320 --> 00:10:51.759
<v Speaker 2>Correct, You still need that HGTPS redirect handled properly first.

227
00:10:52.159 --> 00:10:56.919
<v Speaker 2>Then there's CSP Content Security policy, hugely powerful against EXSS.

228
00:10:57.080 --> 00:10:58.240
<v Speaker 1>How does CSP work.

229
00:10:58.399 --> 00:11:01.320
<v Speaker 2>It's a header listing exactly where the browser is allowed

230
00:11:01.320 --> 00:11:05.559
<v Speaker 2>to load resources from scripts, styles, images, fonts. You can

231
00:11:05.600 --> 00:11:09.320
<v Speaker 2>say self only my own domain, lists specific other domains,

232
00:11:09.399 --> 00:11:10.919
<v Speaker 2>or use nonzs.

233
00:11:10.679 --> 00:11:13.559
<v Speaker 1>Nanzs like a one time code for scripts sort of.

234
00:11:13.759 --> 00:11:17.559
<v Speaker 2>You put a unique random value to actionizez one two

235
00:11:17.600 --> 00:11:19.799
<v Speaker 2>three in the CSB header and also as an attribute

236
00:11:19.799 --> 00:11:22.840
<v Speaker 2>on your legitimate script tags. The browser only runs scripts

237
00:11:22.879 --> 00:11:25.720
<v Speaker 2>that have a matching NONCE blocks injected scripts without the.

238
00:11:25.759 --> 00:11:29.000
<v Speaker 1>Nons clever, But the source mentioned managing conflicts CSPs can

239
00:11:29.080 --> 00:11:29.480
<v Speaker 1>be tricky.

240
00:11:29.679 --> 00:11:32.120
<v Speaker 2>It can be, yeah, especially with lots of third party

241
00:11:32.159 --> 00:11:35.519
<v Speaker 2>scripts or inline styles other key headers. X frame option

242
00:11:35.559 --> 00:11:38.759
<v Speaker 2>stops clickjacking, preventing others from loading your site in an iframe.

243
00:11:39.120 --> 00:11:42.240
<v Speaker 2>X content type option stops browsers from guessing file types

244
00:11:42.519 --> 00:11:44.759
<v Speaker 2>mime sniffing, which can lead to security issues.

245
00:11:45.000 --> 00:11:48.519
<v Speaker 1>Okay, last bit for this section. Storing data between requests.

246
00:11:49.320 --> 00:11:51.320
<v Speaker 1>The web's stateless, so we use things.

247
00:11:51.080 --> 00:11:54.919
<v Speaker 2>Like cookies, hidden fields, and forms each MEL five local

248
00:11:55.000 --> 00:11:56.799
<v Speaker 2>storage and session storage.

249
00:11:56.960 --> 00:12:01.960
<v Speaker 1>Cookies in hidden fields are client side visible, tamparable, risky

250
00:12:02.000 --> 00:12:04.720
<v Speaker 1>for sensitive stuff. You can sign cookies for integrity though.

251
00:12:05.000 --> 00:12:07.399
<v Speaker 2>Right, but here's a major warning from the source about

252
00:12:07.679 --> 00:12:10.320
<v Speaker 2>ASP dot net core's default session storage.

253
00:12:10.440 --> 00:12:11.600
<v Speaker 3>This is really important.

254
00:12:11.720 --> 00:12:12.960
<v Speaker 1>Uh oh, what's the issue?

255
00:12:13.000 --> 00:12:16.679
<v Speaker 2>By default, it's tied to the browser session, not necessarily

256
00:12:16.720 --> 00:12:18.399
<v Speaker 2>the authenticated user session.

257
00:12:18.480 --> 00:12:19.759
<v Speaker 1>What's the difference? Why is that bad?

258
00:12:20.039 --> 00:12:22.000
<v Speaker 2>It means the session cookie might hang around on the

259
00:12:22.000 --> 00:12:25.480
<v Speaker 2>browser even after the user logs out. If someone else

260
00:12:25.519 --> 00:12:28.000
<v Speaker 2>sits down at that same computer and uses the same

261
00:12:28.039 --> 00:12:31.519
<v Speaker 2>browser instance before the browser is fully closed, they might

262
00:12:31.559 --> 00:12:34.759
<v Speaker 2>potentially pick up the previous user's session data because the

263
00:12:34.799 --> 00:12:36.960
<v Speaker 2>cookie is still there and valid for the browser.

264
00:12:37.039 --> 00:12:41.279
<v Speaker 1>WHOA seriously, so logging out doesn't reliably kill the session

265
00:12:41.360 --> 00:12:43.320
<v Speaker 1>data access if the browser stays.

266
00:12:43.080 --> 00:12:47.320
<v Speaker 2>Open in the default configuration. Potentially yes. The source is

267
00:12:47.360 --> 00:12:51.320
<v Speaker 2>extremely clear on this. Do not store sensitive data in

268
00:12:51.440 --> 00:12:55.360
<v Speaker 2>ASP dot net core session state period, use other mechanisms

269
00:12:55.399 --> 00:12:57.440
<v Speaker 2>tied properly to user authentication state.

270
00:12:57.519 --> 00:13:01.120
<v Speaker 1>Okay, that is a massive gotcha. Yeah, message received, loud

271
00:13:01.279 --> 00:13:03.919
<v Speaker 1>and clear. Avoid session for sensitive stuff.

272
00:13:04.120 --> 00:13:06.840
<v Speaker 2>It's a common pattern from older frameworks, but you need

273
00:13:06.879 --> 00:13:09.480
<v Speaker 2>to be aware of this default behavior in ASP don.

274
00:13:09.399 --> 00:13:12.279
<v Speaker 1>Netcre All right, let's shift gears to common attacks. The

275
00:13:12.399 --> 00:13:16.000
<v Speaker 1>vulnerability buffet, as the source calls it. Knowing the enemy

276
00:13:16.039 --> 00:13:20.759
<v Speaker 1>helps us defend. First, the classic injection attacks a wass A.

277
00:13:20.840 --> 00:13:23.960
<v Speaker 2>One, and the king of injection is seql injection. This

278
00:13:24.080 --> 00:13:27.759
<v Speaker 2>happens when user input gets improperly mixed into database queries, like.

279
00:13:27.679 --> 00:13:30.200
<v Speaker 1>Building a sequel string by just sticking user input directly

280
00:13:30.240 --> 00:13:32.759
<v Speaker 1>in select from users where name plus user name.

281
00:13:32.600 --> 00:13:34.879
<v Speaker 2>From the input plus exactly if the attacker puts in

282
00:13:34.960 --> 00:13:37.360
<v Speaker 2>something like or one one, the query becomes selectrom users

283
00:13:37.360 --> 00:13:39.679
<v Speaker 2>whre name or one one, and suddenly the database returns

284
00:13:39.679 --> 00:13:41.080
<v Speaker 2>all users because one one.

285
00:13:40.960 --> 00:13:41.879
<v Speaker 3>Is always true.

286
00:13:42.120 --> 00:13:45.799
<v Speaker 2>The source mentions variations union based to grab data from

287
00:13:45.879 --> 00:13:49.080
<v Speaker 2>other tables, air based, where you use database error messages

288
00:13:49.120 --> 00:13:52.120
<v Speaker 2>to figure out the table structure. There's even a screenshot

289
00:13:52.159 --> 00:13:57.159
<v Speaker 2>example of an error revealing info, and blind techniques where

290
00:13:57.159 --> 00:13:59.360
<v Speaker 2>you infer data slowly bit by bit.

291
00:13:59.720 --> 00:14:03.600
<v Speaker 1>The frorst case is something like xbcmdshell running commands on

292
00:14:03.639 --> 00:14:04.480
<v Speaker 1>the server itself.

293
00:14:04.639 --> 00:14:08.279
<v Speaker 2>Oh yeah, if the database account has way too many permissions,

294
00:14:08.440 --> 00:14:11.679
<v Speaker 2>SQL injection can lead to complete server compromise, So the

295
00:14:11.720 --> 00:14:16.879
<v Speaker 2>defense parameterized queries always. Instead of mashing strings together, you

296
00:14:17.000 --> 00:14:20.679
<v Speaker 2>use placeholders in your sequel like at username, and provide

297
00:14:20.679 --> 00:14:23.720
<v Speaker 2>the user input separately as a parameter. The database driver

298
00:14:23.759 --> 00:14:27.320
<v Speaker 2>handles it safely, treating it purely as data, not executable.

299
00:14:27.360 --> 00:14:30.720
<v Speaker 1>Code and Entity Framework uses these by default.

300
00:14:30.320 --> 00:14:34.039
<v Speaker 2>Mostly yes, for standard link queries and things like save changes.

301
00:14:34.120 --> 00:14:37.960
<v Speaker 2>EF uses parameterized queries, which is great, but there's a buttter.

302
00:14:38.519 --> 00:14:41.000
<v Speaker 2>The source points out what it calls a boneheaded bug,

303
00:14:41.120 --> 00:14:44.159
<v Speaker 2>or at least a risky default feature. Asp net core

304
00:14:44.200 --> 00:14:47.879
<v Speaker 2>apps built with EF migrations might by default prompt you

305
00:14:47.960 --> 00:14:51.159
<v Speaker 2>in production to apply database schema updates. If the code

306
00:14:51.240 --> 00:14:51.919
<v Speaker 2>model changes.

307
00:14:52.279 --> 00:14:55.399
<v Speaker 1>Wait, let the web application change the data base schema

308
00:14:55.440 --> 00:14:56.360
<v Speaker 1>in production.

309
00:14:56.200 --> 00:14:59.440
<v Speaker 2>Exactly the database user account for a running web app.

310
00:14:59.440 --> 00:15:02.720
<v Speaker 2>Should app not have permissions to al your tables or schemas.

311
00:15:03.039 --> 00:15:06.519
<v Speaker 2>That needs strict control through separate deployment processes. It's a

312
00:15:06.600 --> 00:15:07.559
<v Speaker 2>dangerous default.

313
00:15:07.679 --> 00:15:14.519
<v Speaker 1>Yikes. Okay noted Moving on cross site scripting xssas a

314
00:15:14.679 --> 00:15:17.399
<v Speaker 1>seven different target here right, not the.

315
00:15:17.360 --> 00:15:21.240
<v Speaker 2>Database, right, EXSS targets the user's browser. The goal is

316
00:15:21.240 --> 00:15:24.000
<v Speaker 2>to inject malicious JavaScript code that runs in the context

317
00:15:24.039 --> 00:15:26.679
<v Speaker 2>of your website but in another user's browser session.

318
00:15:26.720 --> 00:15:29.279
<v Speaker 1>How by getting script tags into places where user content

319
00:15:29.399 --> 00:15:31.320
<v Speaker 1>is displayed, like comment sections.

320
00:15:31.480 --> 00:15:35.039
<v Speaker 2>That's the classic way, inject script telored EXSS script into

321
00:15:35.039 --> 00:15:37.960
<v Speaker 2>a comment and anyone viewing that comment runs the script.

322
00:15:38.240 --> 00:15:41.440
<v Speaker 2>Attackers get clever though, using case variations like script to

323
00:15:41.519 --> 00:15:44.120
<v Speaker 2>t encoding the script to bypass simple filters.

324
00:15:44.360 --> 00:15:46.960
<v Speaker 1>The source showed an I frame example within coded script

325
00:15:47.000 --> 00:15:50.399
<v Speaker 1>and injecting into HTML attributes like on mouseover.

326
00:15:50.240 --> 00:15:51.240
<v Speaker 3>Yeah, on mousover dot.

327
00:15:51.279 --> 00:15:55.240
<v Speaker 2>Malicious code is a common one or hijacking existing JavaScript

328
00:15:55.279 --> 00:15:58.360
<v Speaker 2>on the page that might process user input insecurely. Some

329
00:15:58.519 --> 00:16:00.799
<v Speaker 2>older vectors are blocked by modern browsers.

330
00:16:00.799 --> 00:16:04.080
<v Speaker 1>Now thankfully, what Was that about value shadowing in older

331
00:16:04.080 --> 00:16:05.000
<v Speaker 1>ASP dot Net?

332
00:16:05.200 --> 00:16:08.840
<v Speaker 2>Ah? Yeah, in older versions, if you had say doc

333
00:16:08.879 --> 00:16:11.240
<v Speaker 2>evil in the URL and also a form field named Q,

334
00:16:11.759 --> 00:16:15.000
<v Speaker 2>the framework might prioritize the URL value made it easier

335
00:16:15.039 --> 00:16:18.240
<v Speaker 2>for attackers to inject scripts via the URL reflected EXSS.

336
00:16:18.360 --> 00:16:21.360
<v Speaker 1>Okay, so defense against XSS. How do we display user

337
00:16:21.399 --> 00:16:22.240
<v Speaker 1>content safely?

338
00:16:22.399 --> 00:16:22.919
<v Speaker 3>In code?

339
00:16:22.960 --> 00:16:25.720
<v Speaker 2>And code and code? Before you render any user supplied

340
00:16:25.720 --> 00:16:29.159
<v Speaker 2>content as HTML, you must encode special characters becomes an

341
00:16:29.279 --> 00:16:32.240
<v Speaker 2>ltcode becomes NGDA, quotes become a ket quote, et cetera.

342
00:16:32.360 --> 00:16:34.519
<v Speaker 1>So the browser just shows the characters, it doesn't interpret

343
00:16:34.519 --> 00:16:35.600
<v Speaker 1>them as code exactly.

344
00:16:35.919 --> 00:16:39.120
<v Speaker 2>The source contrasts at HTML raw, which is dangerous because

345
00:16:39.120 --> 00:16:41.600
<v Speaker 2>it skips encoding with safe methods like system, dot net,

346
00:16:41.639 --> 00:16:45.159
<v Speaker 2>dot web, Utility, dot HTML encode using CSP headers with

347
00:16:45.240 --> 00:16:47.080
<v Speaker 2>nonsas as we discussed, is another.

348
00:16:46.840 --> 00:16:50.080
<v Speaker 1>Strong layer right layers of defense. CSP helps limit what

349
00:16:50.120 --> 00:16:53.480
<v Speaker 1>scripts can run. Encoding stops injection into the HTML structure.

350
00:16:53.639 --> 00:16:57.279
<v Speaker 2>And a brief mention of malvertizing malicious ads delivering scripts.

351
00:16:57.679 --> 00:16:59.600
<v Speaker 2>That's a related risk from third parties.

352
00:17:00.080 --> 00:17:05.240
<v Speaker 1>Okay, next attack, cross site request forgery CSRF. This one

353
00:17:05.319 --> 00:17:06.000
<v Speaker 1>sounds sneaky.

354
00:17:06.119 --> 00:17:09.880
<v Speaker 2>It is CSRF forces a logged in user to unknowingly

355
00:17:09.880 --> 00:17:13.400
<v Speaker 2>submit a malicious request to a website they're authenticated with.

356
00:17:13.799 --> 00:17:14.519
<v Speaker 1>How does that work?

357
00:17:14.839 --> 00:17:17.839
<v Speaker 2>Imagine you're logged into your bank and attacker crafts a

358
00:17:17.880 --> 00:17:20.759
<v Speaker 2>link or a hidden form on say an evil website.

359
00:17:20.920 --> 00:17:23.680
<v Speaker 2>Maybe it's coded to transfer money. If you click that

360
00:17:23.759 --> 00:17:26.119
<v Speaker 2>link or even just load the page with the hidden form,

361
00:17:26.359 --> 00:17:30.680
<v Speaker 2>your browser helpfully includes your bank authentication cookies with the request, So.

362
00:17:30.720 --> 00:17:33.319
<v Speaker 1>The bank thinks you willingly said the transfer request, yeah,

363
00:17:33.400 --> 00:17:34.559
<v Speaker 1>because the cookies are valid.

364
00:17:34.799 --> 00:17:38.880
<v Speaker 2>Exactly, the attacker leverages your authenticated session. The source shows

365
00:17:38.880 --> 00:17:41.960
<v Speaker 2>examples using simple image tags or auto submitting forms.

366
00:17:42.039 --> 00:17:43.440
<v Speaker 1>Nasty. How do we stop that?

367
00:17:43.599 --> 00:17:47.119
<v Speaker 2>The standard defense is anti CSRF tokens. Asp dot core

368
00:17:47.160 --> 00:17:50.480
<v Speaker 2>has built in support with the validate anti forgery token attribute,

369
00:17:50.519 --> 00:17:53.559
<v Speaker 2>and they at html dot Anti forgery Token Helper.

370
00:17:53.599 --> 00:17:54.640
<v Speaker 1>How do those tokens work?

371
00:17:54.880 --> 00:17:57.599
<v Speaker 2>When the server renders a form, it generates a unique,

372
00:17:57.799 --> 00:18:01.200
<v Speaker 2>unpredictable token. It put it's this token in a hidden

373
00:18:01.200 --> 00:18:03.799
<v Speaker 2>field in the form and usually in a cookie. When

374
00:18:03.839 --> 00:18:06.359
<v Speaker 2>the form is submitted back, the server checks that the

375
00:18:06.359 --> 00:18:09.640
<v Speaker 2>token from the form matches the token from the cookie, and.

376
00:18:09.599 --> 00:18:12.079
<v Speaker 1>An attacker on another site can't read the cookie from

377
00:18:12.079 --> 00:18:14.759
<v Speaker 1>my bank site, so they can't forge their request with

378
00:18:14.759 --> 00:18:15.440
<v Speaker 1>the right token.

379
00:18:15.640 --> 00:18:19.279
<v Speaker 2>Precisely the same origin policy prevents them reading the cookie.

380
00:18:19.400 --> 00:18:23.799
<v Speaker 1>However, another however, what's the catch with the default ASP

381
00:18:23.920 --> 00:18:24.960
<v Speaker 1>dot net implementation?

382
00:18:25.319 --> 00:18:28.559
<v Speaker 2>The source points out a potential weakness. While the default

383
00:18:28.599 --> 00:18:32.519
<v Speaker 2>tokens stop trivial CSRF, they are often reusable for the

384
00:18:32.519 --> 00:18:34.880
<v Speaker 2>same user session and can remain valid.

385
00:18:34.559 --> 00:18:37.559
<v Speaker 1>For a while reusable, so if an attacker somehow steals

386
00:18:37.559 --> 00:18:38.319
<v Speaker 1>a valid token.

387
00:18:38.559 --> 00:18:41.440
<v Speaker 2>The source describes the scenario where a token captured from

388
00:18:41.480 --> 00:18:45.240
<v Speaker 2>a user's legitimate request could potentially be replayed later in

389
00:18:45.279 --> 00:18:48.759
<v Speaker 2>a malicious request from that same user's browser context, maybe

390
00:18:48.799 --> 00:18:51.680
<v Speaker 2>via XSS, or if the user revisits a malicious site

391
00:18:51.680 --> 00:18:55.240
<v Speaker 2>while still logged in. The default token isn't strictly single

392
00:18:55.359 --> 00:18:58.160
<v Speaker 2>use or tied tightly enough to expire immediately when it

393
00:18:58.200 --> 00:18:58.880
<v Speaker 2>perhaps should.

394
00:18:59.000 --> 00:19:02.160
<v Speaker 1>Wow. Okay, so better than nothing, but not perfect out

395
00:19:02.160 --> 00:19:02.640
<v Speaker 1>of the box.

396
00:19:03.079 --> 00:19:04.400
<v Speaker 3>Needs tightening, seems so.

397
00:19:05.240 --> 00:19:08.960
<v Speaker 2>The fix involves custom code using IANTI forgery, additional data

398
00:19:08.960 --> 00:19:13.240
<v Speaker 2>provider or cookie authentication events to make tokens more strictly

399
00:19:13.319 --> 00:19:17.440
<v Speaker 2>session bound or truly single use. Katcchase can also help

400
00:19:17.480 --> 00:19:19.920
<v Speaker 2>against automated CSRF attemps.

401
00:19:19.559 --> 00:19:22.039
<v Speaker 1>Okay, another vulnerability mass assignment.

402
00:19:22.319 --> 00:19:25.440
<v Speaker 2>This happens when your application blindly accepts and binds all

403
00:19:25.519 --> 00:19:28.480
<v Speaker 2>data submitted in a request to your back end model object,

404
00:19:28.799 --> 00:19:31.400
<v Speaker 2>even properties the user shouldn't be allowed to change through

405
00:19:31.440 --> 00:19:33.000
<v Speaker 2>that specific form or API.

406
00:19:33.119 --> 00:19:36.119
<v Speaker 1>Call the blog post example from the source right A

407
00:19:36.160 --> 00:19:39.079
<v Speaker 1>form lets users edit title and content, but the underlying

408
00:19:39.119 --> 00:19:42.440
<v Speaker 1>blog post object also has like an is published flag

409
00:19:42.519 --> 00:19:43.440
<v Speaker 1>or a created date.

410
00:19:43.599 --> 00:19:46.319
<v Speaker 2>Exactly if your update action just takes all submitted data

411
00:19:46.400 --> 00:19:49.160
<v Speaker 2>from form fields, query, string, et cetera and applies it

412
00:19:49.200 --> 00:19:51.720
<v Speaker 2>to the blog post object loaded from the database.

413
00:19:51.319 --> 00:19:54.359
<v Speaker 1>An attacker could add any published true to the URL

414
00:19:54.799 --> 00:19:57.839
<v Speaker 1>or slip in input type hidden name is published value

415
00:19:57.880 --> 00:19:59.319
<v Speaker 1>true into the form they.

416
00:19:59.160 --> 00:20:03.599
<v Speaker 2>Submit yep, And because of default model binding behaviors including

417
00:20:03.640 --> 00:20:07.200
<v Speaker 2>that value shadowing issue again, the framework might just obediently

418
00:20:07.319 --> 00:20:10.039
<v Speaker 2>update the es published property even though the UI form

419
00:20:10.119 --> 00:20:11.599
<v Speaker 2>never showed that field.

420
00:20:11.480 --> 00:20:15.359
<v Speaker 1>So they bypass authorization checks by manipulating the data binding.

421
00:20:15.440 --> 00:20:16.279
<v Speaker 1>How do you fix that?

422
00:20:16.960 --> 00:20:20.440
<v Speaker 2>Use specific view models or data transfer objects DTOs for

423
00:20:20.559 --> 00:20:24.480
<v Speaker 2>each form or API endpoint. These models should only include

424
00:20:24.519 --> 00:20:27.119
<v Speaker 2>the properties that are legitimately allowed to be updated in

425
00:20:27.160 --> 00:20:30.599
<v Speaker 2>that context. Don't bind directly to your full database entities

426
00:20:30.599 --> 00:20:33.559
<v Speaker 2>for updates coming from the user, be explicit.

427
00:20:33.160 --> 00:20:36.000
<v Speaker 1>Got it only allowed binding for fields you actually intend

428
00:20:36.039 --> 00:20:37.559
<v Speaker 1>to change on that screen exactly.

429
00:20:37.680 --> 00:20:40.839
<v Speaker 2>The source also briefly mentions other things like insecure direct

430
00:20:40.839 --> 00:20:44.000
<v Speaker 2>object references ide yours like changing order EQUIDLA one two

431
00:20:44.000 --> 00:20:46.039
<v Speaker 2>three in the URL to order lvdno one two four

432
00:20:46.119 --> 00:20:49.480
<v Speaker 2>to see someone else's order OS command injection, directory traversal,

433
00:20:49.799 --> 00:20:53.759
<v Speaker 2>super careful with filepaths, business logic abuse, using the app

434
00:20:53.759 --> 00:20:58.279
<v Speaker 2>in weird ways, session hijacking, response splitting, parameter pollution, lots

435
00:20:58.279 --> 00:20:59.920
<v Speaker 2>to be aware of a minefield.

436
00:21:00.680 --> 00:21:04.839
<v Speaker 1>Okay, let's talk about access control itself authentication first. Proving

437
00:21:04.839 --> 00:21:09.680
<v Speaker 1>who you are O SPA two. Passwords are the old way, but.

438
00:21:10.000 --> 00:21:14.480
<v Speaker 2>Problematic, hugely problematic. People choose weak ones reuse them everywhere,

439
00:21:14.799 --> 00:21:16.640
<v Speaker 2>which leads to credential stuffing.

440
00:21:16.799 --> 00:21:19.480
<v Speaker 1>Yeah, that's where attackers take lists of leak usernames and

441
00:21:19.519 --> 00:21:21.119
<v Speaker 1>passwords from one breach and just.

442
00:21:21.119 --> 00:21:23.440
<v Speaker 2>Try them automatically on tons of other sites. And it

443
00:21:23.480 --> 00:21:26.079
<v Speaker 2>works depressingly often because of password reuse.

444
00:21:26.200 --> 00:21:29.880
<v Speaker 1>So we need better than just passwords. Multi factor authentication MFA.

445
00:21:30.079 --> 00:21:33.519
<v Speaker 2>Using something you know password plus something you have phone

446
00:21:33.559 --> 00:21:36.279
<v Speaker 2>for a code authenticator app hard work key or something

447
00:21:36.480 --> 00:21:40.319
<v Speaker 2>you are fingerprint face. It makes credential stuffing much much harder.

448
00:21:40.839 --> 00:21:44.079
<v Speaker 2>Other defenses include checking logins against breach lists like have

449
00:21:44.200 --> 00:21:47.720
<v Speaker 2>I Been Pound or detecting logins from weird locations.

450
00:21:47.799 --> 00:21:51.319
<v Speaker 1>Now the source dives into asp dot it's default authentication.

451
00:21:52.000 --> 00:21:54.319
<v Speaker 1>It criticizes using email as the username.

452
00:21:54.480 --> 00:21:58.160
<v Speaker 2>Yeah, because failed login attempts can inadvertently confirm whether an

453
00:21:58.160 --> 00:22:01.240
<v Speaker 2>email address is registered or not, which is information linkage.

454
00:22:01.440 --> 00:22:04.680
<v Speaker 2>And it highlights a subtle timing attack vulnerability.

455
00:22:04.119 --> 00:22:06.319
<v Speaker 1>Timing attack on a login page.

456
00:22:06.480 --> 00:22:09.839
<v Speaker 2>It's clever and sneaky. An attacker sends lots of logan

457
00:22:09.880 --> 00:22:13.119
<v Speaker 2>attempts with a known bad password, but tries different usernames.

458
00:22:13.519 --> 00:22:17.119
<v Speaker 2>The code path inside the application might take fractionally longer

459
00:22:17.119 --> 00:22:20.480
<v Speaker 2>milliseconds to process a request for a valid username because

460
00:22:20.480 --> 00:22:23.400
<v Speaker 2>it finds the user than checks the password compared to

461
00:22:23.440 --> 00:22:25.480
<v Speaker 2>an invalid username, where it fails.

462
00:22:25.160 --> 00:22:29.039
<v Speaker 1>Faster, and attackers can measure that tiny time difference.

463
00:22:28.799 --> 00:22:29.880
<v Speaker 3>With automated tools.

464
00:22:30.039 --> 00:22:32.799
<v Speaker 2>Yes, they can use that timing difference to figure out

465
00:22:32.799 --> 00:22:35.960
<v Speaker 2>which usernames are registered on the system, even without guessing

466
00:22:36.000 --> 00:22:36.920
<v Speaker 2>any passwords.

467
00:22:37.039 --> 00:22:39.599
<v Speaker 1>Wow, that's subtle, it is.

468
00:22:40.160 --> 00:22:42.759
<v Speaker 2>The fix is to make the code paths for valid

469
00:22:42.759 --> 00:22:45.440
<v Speaker 2>and invalid user names take as close to the identical

470
00:22:45.440 --> 00:22:49.240
<v Speaker 2>amount of time as possible constant time comparison logic.

471
00:22:49.319 --> 00:22:52.680
<v Speaker 1>And there's another warning about asp nets default authentication cookie

472
00:22:52.720 --> 00:22:55.640
<v Speaker 1>session token similar to the CSRF token thing.

473
00:22:55.920 --> 00:22:59.240
<v Speaker 2>Yes, another default behavior. To be very aware of the

474
00:22:59.279 --> 00:23:02.039
<v Speaker 2>source demonstration, it's using tools like burpsuite how the standard

475
00:23:02.039 --> 00:23:05.559
<v Speaker 2>authentication cookie might be reusable even after the user explicitly

476
00:23:05.599 --> 00:23:08.279
<v Speaker 2>logs out or after the server side session should have

477
00:23:08.279 --> 00:23:10.319
<v Speaker 2>logically expired based on inactivity.

478
00:23:10.599 --> 00:23:14.680
<v Speaker 1>Seriously, so logging out doesn't necessarily invalidate the off cookie

479
00:23:14.759 --> 00:23:18.720
<v Speaker 1>immediately or reliably. By default, stealing one could give longer

480
00:23:18.759 --> 00:23:19.839
<v Speaker 1>access than expected.

481
00:23:19.920 --> 00:23:23.599
<v Speaker 2>Potentially, Yes, the default linkage between the off cookie's validity

482
00:23:23.640 --> 00:23:26.000
<v Speaker 2>and the service side session state isn't as tight as

483
00:23:26.000 --> 00:23:29.559
<v Speaker 2>you might assume. It makes cookie theft potentially more impactful.

484
00:23:29.720 --> 00:23:31.759
<v Speaker 1>Okay, so what's the fix there? Custom code again?

485
00:23:31.799 --> 00:23:32.359
<v Speaker 3>Pretty much?

486
00:23:32.799 --> 00:23:36.400
<v Speaker 2>It again involves hooking into cookie authentication events to add

487
00:23:36.440 --> 00:23:39.960
<v Speaker 2>server side validation, checking a database flag, for instance, to

488
00:23:40.119 --> 00:23:43.279
<v Speaker 2>ensure the session associated with that cookie is still considered

489
00:23:43.319 --> 00:23:46.279
<v Speaker 2>valid by the server on every request, not just relying

490
00:23:46.319 --> 00:23:48.039
<v Speaker 2>on the cookie's own expiration.

491
00:23:47.680 --> 00:23:50.480
<v Speaker 1>Time makes sense. You need service side control over session

492
00:23:50.519 --> 00:23:54.920
<v Speaker 1>validity for MFA and ASP dot net. What options does

493
00:23:55.000 --> 00:23:56.160
<v Speaker 1>the source mention.

494
00:23:56.200 --> 00:24:00.559
<v Speaker 2>The usual suspects? SMS codes easy but vulnerable to swapping.

495
00:24:00.960 --> 00:24:05.000
<v Speaker 2>Authenticator apps like Google or Microsoft Authenticator better based on

496
00:24:05.039 --> 00:24:09.039
<v Speaker 2>TOTP and hardware key is like Ubikey's generally considered strongest uses.

497
00:24:09.079 --> 00:24:10.480
<v Speaker 2>Protocols like Phytoto, Web.

498
00:24:10.319 --> 00:24:13.680
<v Speaker 1>Authen and the simple baseline require authentication globally.

499
00:24:13.960 --> 00:24:17.079
<v Speaker 2>Yeah, using things like authorized folder or global filters is

500
00:24:17.119 --> 00:24:20.279
<v Speaker 2>a good safety net to prevent accidentally leaving pages unprotected.

501
00:24:20.440 --> 00:24:26.839
<v Speaker 1>Okay, so that's authentication. What about authorization AISPA five What

502
00:24:26.920 --> 00:24:28.480
<v Speaker 1>you can do once you're logged in?

503
00:24:28.680 --> 00:24:31.160
<v Speaker 2>First, let's repeat the mantra because it applies here too.

504
00:24:31.400 --> 00:24:35.319
<v Speaker 2>Avoids storing sensitive data or authorization decisions purely in session

505
00:24:35.359 --> 00:24:37.680
<v Speaker 2>state due to that cookie persistence issue.

506
00:24:37.759 --> 00:24:40.839
<v Speaker 1>Right, So basic authorization roles.

507
00:24:40.920 --> 00:24:44.759
<v Speaker 2>Role based authorization is the simplest. Define roles like admin

508
00:24:45.079 --> 00:24:49.839
<v Speaker 2>manager user and use attributes like authorized roles admin manager

509
00:24:49.920 --> 00:24:53.480
<v Speaker 2>to restrict access to controllers or actions. Easy to understand,

510
00:24:53.599 --> 00:24:56.480
<v Speaker 2>easy to implement for broad categories.

511
00:24:56.039 --> 00:24:57.839
<v Speaker 1>But sometimes you need finder control.

512
00:24:57.920 --> 00:25:00.960
<v Speaker 2>That's where claims based authorization comes in. A claim is

513
00:25:01.000 --> 00:25:04.000
<v Speaker 2>a specific piece of information about the user like department

514
00:25:04.279 --> 00:25:07.519
<v Speaker 2>sales or can approve expenses true. You can then create

515
00:25:07.559 --> 00:25:10.960
<v Speaker 2>policies based on these claims like authorized policy must be

516
00:25:11.000 --> 00:25:13.200
<v Speaker 2>in sales department much more granular.

517
00:25:13.240 --> 00:25:16.240
<v Speaker 1>And then there's context specific authorization making sure users only

518
00:25:16.240 --> 00:25:16.680
<v Speaker 1>see their.

519
00:25:16.559 --> 00:25:20.720
<v Speaker 2>Own stuff crucial in multi user systems. The source shows

520
00:25:20.759 --> 00:25:24.400
<v Speaker 2>some neat patterns for handling this, especially with entity framework

521
00:25:24.799 --> 00:25:28.720
<v Speaker 2>ideas like using custom attributes, say user filterable on your

522
00:25:28.799 --> 00:25:31.440
<v Speaker 2>database entities, and how would that work? You'd combine it

523
00:25:31.480 --> 00:25:34.799
<v Speaker 2>with maybe a base repository or helper methods like single

524
00:25:34.880 --> 00:25:39.079
<v Speaker 2>en user context ITEMID. Behind the scenes, it automatically adds

525
00:25:39.160 --> 00:25:42.839
<v Speaker 2>a ware x user x user current user a clause

526
00:25:42.880 --> 00:25:45.160
<v Speaker 2>to the database query based on the logged in user.

527
00:25:45.599 --> 00:25:48.319
<v Speaker 2>You define a user filter expression once and it gets

528
00:25:48.359 --> 00:25:49.319
<v Speaker 2>applied consistently.

529
00:25:49.680 --> 00:25:52.039
<v Speaker 1>Ah, so it builds the user filtering right into the

530
00:25:52.119 --> 00:25:55.720
<v Speaker 1>data access layer automatically. That sounds way less error prone

531
00:25:55.759 --> 00:25:58.039
<v Speaker 1>than remembering to add were clauses everywhere.

532
00:25:58.119 --> 00:26:00.720
<v Speaker 2>It can be a really powerful pattern for venting users

533
00:26:00.720 --> 00:26:04.440
<v Speaker 2>from accessing data they shouldn't implicitly handling many ID or scenarios.

534
00:26:04.599 --> 00:26:09.039
<v Speaker 1>If done right, cool, okay, logging air handling OSBA ten

535
00:26:09.680 --> 00:26:13.039
<v Speaker 1>Why is logging so critical for security, specifically.

536
00:26:12.480 --> 00:26:13.640
<v Speaker 3>Because detection is key.

537
00:26:13.720 --> 00:26:17.640
<v Speaker 2>Most standard application logging tracks functional errors or performance. Security

538
00:26:17.680 --> 00:26:20.720
<v Speaker 2>logging is about spotting signs of an attack. Hackers often

539
00:26:20.759 --> 00:26:23.960
<v Speaker 2>count on systems not logging the suspicious stuff they do, and.

540
00:26:24.000 --> 00:26:27.519
<v Speaker 1>The default ASP dot net core log levels aren't really

541
00:26:27.519 --> 00:26:28.000
<v Speaker 1>cut out.

542
00:26:27.960 --> 00:26:32.160
<v Speaker 2>For this, not really info warning error critical, they're about

543
00:26:32.240 --> 00:26:36.960
<v Speaker 2>application health. The source suggests creating custom security log levels

544
00:26:37.039 --> 00:26:40.960
<v Speaker 2>like what things like security alert, security, audit, security success.

545
00:26:41.440 --> 00:26:44.880
<v Speaker 2>This lets you specifically tag events like failed login bursts,

546
00:26:45.400 --> 00:26:49.799
<v Speaker 2>access attempts on sensitive resources, successful logins from new locations,

547
00:26:49.839 --> 00:26:54.119
<v Speaker 2>potential policy violations, things and security monitoring system should actually

548
00:26:54.119 --> 00:26:54.559
<v Speaker 2>care about.

549
00:26:54.599 --> 00:26:56.720
<v Speaker 1>So you filter logs on these custom levels to build

550
00:26:56.759 --> 00:26:59.319
<v Speaker 1>an audit trail or trigger alerts for security teams.

551
00:26:59.440 --> 00:27:02.839
<v Speaker 2>Exactly, it separates the security signal from the application noise.

552
00:27:03.160 --> 00:27:05.359
<v Speaker 2>Honeypots are a great example of using this.

553
00:27:05.559 --> 00:27:08.039
<v Speaker 1>Honeypots like fake targets.

554
00:27:07.680 --> 00:27:11.000
<v Speaker 2>YEP setting up decoy resources that look tempting to attackers

555
00:27:11.000 --> 00:27:14.200
<v Speaker 2>but have no legitimate use, maybe a fake admin login

556
00:27:14.319 --> 00:27:17.480
<v Speaker 2>page of wpadmin on your non WordPress site or a

557
00:27:17.480 --> 00:27:19.720
<v Speaker 2>fake sensitive API endpoint.

558
00:27:19.440 --> 00:27:22.799
<v Speaker 1>And any traffic hitting those is automatically suspicious.

559
00:27:22.440 --> 00:27:25.720
<v Speaker 2>Highly suspicious. You log any access attempt to a honeypot

560
00:27:25.759 --> 00:27:29.200
<v Speaker 2>with a high priority security level like security critical. It's

561
00:27:29.240 --> 00:27:32.039
<v Speaker 2>a great way to detect scanners and bots early. You

562
00:27:32.039 --> 00:27:35.000
<v Speaker 2>could even use that logging to trigger automated blocking, maybe

563
00:27:35.079 --> 00:27:37.599
<v Speaker 2>using an attribute concept like block flocked out that the

564
00:27:37.640 --> 00:27:38.720
<v Speaker 2>source mentions.

565
00:27:38.519 --> 00:27:41.519
<v Speaker 1>Cliver and on error handling, the key message is.

566
00:27:41.920 --> 00:27:46.119
<v Speaker 2>Don't swallow errors silently. Users need feedback, but also don't

567
00:27:46.119 --> 00:27:49.559
<v Speaker 2>show detailed stack traces or internal system information in production

568
00:27:49.680 --> 00:27:52.880
<v Speaker 2>error messages. Provide a user friendly error page. Log the

569
00:27:52.920 --> 00:27:56.039
<v Speaker 2>detailed server side for debugging, but don't leak info to

570
00:27:56.039 --> 00:27:56.960
<v Speaker 2>potential attackers.

571
00:27:57.079 --> 00:27:59.640
<v Speaker 1>Makes sense, okay. Final stretch in this section setup and

572
00:27:59.640 --> 00:28:01.759
<v Speaker 1>can figure curation, basic server.

573
00:28:01.519 --> 00:28:03.279
<v Speaker 3>Hardening, foundational stuff.

574
00:28:03.519 --> 00:28:06.480
<v Speaker 2>Don't let users upload files directly into folders served by

575
00:28:06.480 --> 00:28:10.720
<v Speaker 2>the web server. Sanitize user provided filenames, turn off directory browsing.

576
00:28:11.039 --> 00:28:15.039
<v Speaker 2>Don't use default install paths for servers if possible. Disabled services.

577
00:28:15.079 --> 00:28:17.720
<v Speaker 2>You don't need cy sugmind one oh one, but.

578
00:28:17.759 --> 00:28:20.960
<v Speaker 1>Crucial network security firewalls.

579
00:28:20.519 --> 00:28:24.079
<v Speaker 2>Absolutely segment your network web server, database server, mail server.

580
00:28:24.680 --> 00:28:28.160
<v Speaker 2>They should be separate, ideally with firewalls between them, allowing

581
00:28:28.160 --> 00:28:32.160
<v Speaker 2>only the specific ports needed. The database server should definitely

582
00:28:32.200 --> 00:28:34.440
<v Speaker 2>not be directly reachable from the public.

583
00:28:34.119 --> 00:28:36.519
<v Speaker 1>Internet secrets management. This sounds critical.

584
00:28:36.599 --> 00:28:37.480
<v Speaker 3>It is paramount.

585
00:28:37.519 --> 00:28:42.559
<v Speaker 2>Do not store database connection strings, API keys, encryption keys, passwords,

586
00:28:42.559 --> 00:28:46.079
<v Speaker 2>and config files like app settings dot json, especially if

587
00:28:46.200 --> 00:28:47.240
<v Speaker 2>checked into source.

588
00:28:46.960 --> 00:28:49.480
<v Speaker 1>Control, even if they're encryptive and the canfig file.

589
00:28:49.640 --> 00:28:52.160
<v Speaker 2>Even then, because now you have the problem of managing

590
00:28:52.200 --> 00:28:55.319
<v Speaker 2>the decryption key securely. Where do you put that? It

591
00:28:55.400 --> 00:28:58.960
<v Speaker 2>just moves the problem. Better options are dedicated secrets management

592
00:28:59.000 --> 00:29:03.400
<v Speaker 2>tools like Hashi Court Vault environment variables and injected securely

593
00:29:03.400 --> 00:29:06.599
<v Speaker 2>by the hosted platform or perhaps a separate, tightly secured

594
00:29:06.640 --> 00:29:07.839
<v Speaker 2>configuration database.

595
00:29:08.359 --> 00:29:10.880
<v Speaker 3>Keep secrets out of your code repository, got.

596
00:29:10.799 --> 00:29:14.799
<v Speaker 1>It HTTPS everywhere we've covered adding security headers in ASP

597
00:29:14.880 --> 00:29:15.559
<v Speaker 1>dot net core.

598
00:29:15.720 --> 00:29:19.240
<v Speaker 2>Usually done in startup dot cs using middleware adding headers

599
00:29:19.319 --> 00:29:23.000
<v Speaker 2>like x frame options, x content type options, hsts, CSP

600
00:29:23.160 --> 00:29:29.160
<v Speaker 2>globally for page specific things like maybe very strict caching directives,

601
00:29:29.240 --> 00:29:32.359
<v Speaker 2>cash control dot no store no cash on a page

602
00:29:32.359 --> 00:29:35.279
<v Speaker 2>displaying sensitive data. You can often use attributes on the

603
00:29:35.279 --> 00:29:36.079
<v Speaker 2>controller action.

604
00:29:36.359 --> 00:29:39.200
<v Speaker 1>Third party components libraries, new get packages.

605
00:29:39.039 --> 00:29:41.839
<v Speaker 2>Big source of risk. If a library you depend on

606
00:29:41.880 --> 00:29:46.000
<v Speaker 2>has a vulnerability, your application is vulnerable. So vet your dependencies.

607
00:29:46.279 --> 00:29:49.519
<v Speaker 2>Use reputable sources, keep them updated and understand the risks.

608
00:29:49.880 --> 00:29:53.000
<v Speaker 2>The source warns, though, that updates don't catch everything, and

609
00:29:53.079 --> 00:29:55.160
<v Speaker 2>many vulnerabilities aren't public knowledge.

610
00:29:55.279 --> 00:29:58.480
<v Speaker 1>Tools like o WASP dependency check help find known issues

611
00:29:58.480 --> 00:29:59.160
<v Speaker 1>in libraries.

612
00:29:59.319 --> 00:30:03.240
<v Speaker 2>Yes, Component Analysis SAA very useful for catching known cvees

613
00:30:03.319 --> 00:30:04.200
<v Speaker 2>in your dependencies.

614
00:30:04.200 --> 00:30:07.279
<v Speaker 1>What about integrity hashes sub resource integrity.

615
00:30:07.480 --> 00:30:10.599
<v Speaker 2>That's a browser feature for a third party javascripts CSS

616
00:30:10.640 --> 00:30:13.920
<v Speaker 2>loaded from CDNs. In your script or link tag, you

617
00:30:14.000 --> 00:30:17.519
<v Speaker 2>include a cryptographic hash integrity of the file you expect.

618
00:30:17.839 --> 00:30:21.160
<v Speaker 2>The browser downloads the file, hashes it, and only run

619
00:30:21.200 --> 00:30:24.480
<v Speaker 2>supplies it if the hash matches yours. Protects against the

620
00:30:24.480 --> 00:30:27.799
<v Speaker 2>CDN being compromised or the file being modified and transit.

621
00:30:27.960 --> 00:30:31.680
<v Speaker 1>Neat and finally, test environments need security.

622
00:30:31.240 --> 00:30:33.039
<v Speaker 3>Too, absolutely key rules.

623
00:30:33.519 --> 00:30:36.640
<v Speaker 2>Never use real production data and test of environments ever.

624
00:30:37.200 --> 00:30:40.799
<v Speaker 2>Keep test systems behind firewalls, not exposed publicly. Don't rely

625
00:30:40.920 --> 00:30:42.920
<v Speaker 2>on it's just a test server. Nobody will find it.

626
00:30:42.960 --> 00:30:45.119
<v Speaker 2>Obscurity isn't security here either, lock them down.

627
00:30:45.240 --> 00:30:47.400
<v Speaker 1>Okay, that's a ton of ground on a tax defenses

628
00:30:47.400 --> 00:30:50.359
<v Speaker 1>and config Let's talk about the ongoing process, a security

629
00:30:50.400 --> 00:30:53.039
<v Speaker 1>life cycle, testing learning. It's not a one time thing.

630
00:30:53.119 --> 00:30:54.599
<v Speaker 3>Definitely not. You have to keep testing.

631
00:30:54.839 --> 00:30:58.079
<v Speaker 2>The source talks about different tool types. First, DAST dynamic

632
00:30:58.119 --> 00:30:59.599
<v Speaker 2>application security testing.

633
00:30:59.720 --> 00:31:02.240
<v Speaker 1>These test the running application from the outside like a

634
00:31:02.240 --> 00:31:06.680
<v Speaker 1>black box hacker tools like burpsuite oas, dayzap exactly.

635
00:31:07.000 --> 00:31:10.759
<v Speaker 2>They send malicious looking requests probe for common vulnerabilities on

636
00:31:10.839 --> 00:31:14.559
<v Speaker 2>the live site or API. Good for finding run time issues.

637
00:31:15.039 --> 00:31:18.519
<v Speaker 2>The downside, they could be noisy, lots of false positives

638
00:31:18.680 --> 00:31:22.039
<v Speaker 2>and they don't see the underlying code. Using multiple DAFs

639
00:31:22.079 --> 00:31:22.920
<v Speaker 2>tools can help.

640
00:31:23.240 --> 00:31:25.720
<v Speaker 1>Then there's SaaS Static Application security Testing.

641
00:31:26.119 --> 00:31:29.400
<v Speaker 2>SAAST analyzes the source code directly without running it white

642
00:31:29.440 --> 00:31:32.440
<v Speaker 2>box testing. For dot net there are tools like the

643
00:31:32.440 --> 00:31:36.240
<v Speaker 2>Prima Security Scanner built in Rosalin analyzers and commercial options.

644
00:31:36.599 --> 00:31:37.480
<v Speaker 3>They can find.

645
00:31:37.200 --> 00:31:40.079
<v Speaker 2>Flaws in the code logic that DAST might miss, but

646
00:31:40.119 --> 00:31:42.640
<v Speaker 2>they also have their own types of noise and limitations.

647
00:31:42.680 --> 00:31:46.680
<v Speaker 1>And SEA Source component analysis we mentioned checks library dependencies

648
00:31:46.720 --> 00:31:48.559
<v Speaker 1>for known vulnerabilities.

649
00:31:48.000 --> 00:31:52.039
<v Speaker 2>Right like OAST dependency check. Crucial Reminder finds known issues only,

650
00:31:52.400 --> 00:31:54.640
<v Speaker 2>not zero days, not flaws unique to.

651
00:31:54.640 --> 00:31:55.880
<v Speaker 3>How you use the library.

652
00:31:56.119 --> 00:31:57.160
<v Speaker 1>I is also mentioned.

653
00:31:57.319 --> 00:32:00.680
<v Speaker 2>Interactive Application security testing sort of a hybrid. IT instruments

654
00:32:00.680 --> 00:32:03.640
<v Speaker 2>the running application to combine dynamic testing with runtime code

655
00:32:03.680 --> 00:32:07.640
<v Speaker 2>analysis still evolving, less common maybe, but promising.

656
00:32:07.839 --> 00:32:10.319
<v Speaker 1>So lots of tools. What's the big caveat.

657
00:32:09.960 --> 00:32:12.480
<v Speaker 3>The source is very clear and realistic here.

658
00:32:13.079 --> 00:32:16.440
<v Speaker 2>None of these automated tools find everything they're good at,

659
00:32:16.480 --> 00:32:20.680
<v Speaker 2>finding the low hanging fruit, the common, easy to spot vulnerabilities.

660
00:32:21.039 --> 00:32:24.559
<v Speaker 2>Relying only on scanners will lead to breaches. Their helpers

661
00:32:24.839 --> 00:32:26.640
<v Speaker 2>supplements not a silver bullet.

662
00:32:26.680 --> 00:32:30.240
<v Speaker 1>Gotcha tools help but don't replace human review and secure design.

663
00:32:30.759 --> 00:32:32.160
<v Speaker 1>Callie Linux gets a mention.

664
00:32:32.519 --> 00:32:36.319
<v Speaker 2>Yeah, the Linux distro packed with security tools. The source

665
00:32:36.359 --> 00:32:39.559
<v Speaker 2>suggests pragmatically that maybe it's easier just to install the

666
00:32:39.599 --> 00:32:42.839
<v Speaker 2>specific tools you actually need, like ZAP or BURP, on

667
00:32:42.880 --> 00:32:45.440
<v Speaker 2>your regular development machine, rather than switching to a whole

668
00:32:45.440 --> 00:32:47.240
<v Speaker 2>new OS you might not be familiar with.

669
00:32:47.440 --> 00:32:50.480
<v Speaker 1>Makes sense integrating these tools into CICD.

670
00:32:50.640 --> 00:32:51.960
<v Speaker 3>That's the goal for many teams.

671
00:32:52.240 --> 00:32:56.279
<v Speaker 2>Run safety and SEA automatically on every build or pull request,

672
00:32:56.519 --> 00:32:59.440
<v Speaker 2>maybe fail the build if high severity vulnerabilities are found.

673
00:32:59.440 --> 00:33:02.960
<v Speaker 2>Helps catch things early. The challenge is managing the findings,

674
00:33:03.039 --> 00:33:05.240
<v Speaker 2>tuning the tools to reduce false positives.

675
00:33:05.480 --> 00:33:10.240
<v Speaker 4>Code reviews, specifically for security highly recommended separate from functional reviews,

676
00:33:10.240 --> 00:33:13.240
<v Speaker 4>have developers specifically look at code changes just through a

677
00:33:13.240 --> 00:33:17.200
<v Speaker 4>security lens, helps build awareness and spot issues tools might miss.

678
00:33:17.480 --> 00:33:21.240
<v Speaker 1>And finally, penetration testing hiring the pros.

679
00:33:21.039 --> 00:33:25.000
<v Speaker 2>Yep, ethical hackers, but the source warns strongly against just

680
00:33:25.079 --> 00:33:27.960
<v Speaker 2>hiring someone cheap who runs the same automated scanners you

681
00:33:27.960 --> 00:33:28.880
<v Speaker 2>could run yourself.

682
00:33:28.960 --> 00:33:30.680
<v Speaker 1>What should a good pen test involve?

683
00:33:31.160 --> 00:33:36.200
<v Speaker 2>A proper test follows the attacker methodology, reconnaissance, scanning, and enumeration,

684
00:33:36.680 --> 00:33:41.559
<v Speaker 2>actually trying to gain access, attempting to maintain access, persistence,

685
00:33:41.640 --> 00:33:45.000
<v Speaker 2>and maybe covering tracks. They should demonstrate the impact of

686
00:33:45.000 --> 00:33:46.599
<v Speaker 2>the vulnerabilities found.

687
00:33:46.559 --> 00:33:49.400
<v Speaker 1>Seeing what a skilled human attacker can actually achieve with

688
00:33:49.480 --> 00:33:50.000
<v Speaker 1>your system.

689
00:33:50.880 --> 00:33:54.920
<v Speaker 2>That sounds valuable, incredibly valuable for understanding your real world risk.

690
00:33:55.359 --> 00:33:58.400
<v Speaker 2>For learning more, The source points to resources like the

691
00:33:58.440 --> 00:34:02.039
<v Speaker 2>Web Application Hackers Handbook, a classic deep dive, the Daily

692
00:34:02.079 --> 00:34:05.680
<v Speaker 2>Swig for News, Troy Hunt's blog for great practical insights,

693
00:34:05.880 --> 00:34:09.400
<v Speaker 2>SERTs like CECHCISSP grapped or mentioned too.

694
00:34:09.639 --> 00:34:11.559
<v Speaker 1>And maybe the best way to learn is just doing it.

695
00:34:11.719 --> 00:34:13.920
<v Speaker 1>Setting up vulnerable apps and trying to break.

696
00:34:13.679 --> 00:34:18.800
<v Speaker 2>Them absolutely hands on practice, experimentation, staying curious. That's huge insecurity.

697
00:34:19.199 --> 00:34:22.519
<v Speaker 1>So wow, we've really journeyed through this material kicked off

698
00:34:22.519 --> 00:34:26.920
<v Speaker 1>with security fundamentals CIA triad attacker steps dived into crypto

699
00:34:27.000 --> 00:34:30.360
<v Speaker 1>web basics like htpps and headers, but always with that

700
00:34:30.400 --> 00:34:31.119
<v Speaker 1>security angle.

701
00:34:32.079 --> 00:34:37.760
<v Speaker 2>Then hit the big vulnerabilities SQL injection, xss, CSRF, mass assignment,

702
00:34:38.079 --> 00:34:42.280
<v Speaker 2>looking specifically at ASP dot net Core three defenses and

703
00:34:42.920 --> 00:34:46.199
<v Speaker 2>importantly those default behaviors you need to watch out for right.

704
00:34:46.079 --> 00:34:49.320
<v Speaker 1>Like the session state and authentication cookie issues, covered secure

705
00:34:49.320 --> 00:34:52.039
<v Speaker 1>setup config secrets management, third party.

706
00:34:51.880 --> 00:34:54.559
<v Speaker 2>Risks, and wrapped up with the testing life cycle dast

707
00:34:54.760 --> 00:34:58.239
<v Speaker 2>sessed SCA, the limits of tools, importance of code review,

708
00:34:58.320 --> 00:34:59.960
<v Speaker 2>pen testing and continuous learning.

709
00:35:00.360 --> 00:35:03.239
<v Speaker 1>The big takeaway seems to be security is not a

710
00:35:03.280 --> 00:35:06.320
<v Speaker 1>feature you bolt on at the end. It's an ongoing process,

711
00:35:06.440 --> 00:35:09.159
<v Speaker 1>layers of defense, constant vigilance exactly.

712
00:35:09.199 --> 00:35:12.519
<v Speaker 2>It's about balancing the tech the business needs, the user experience.

713
00:35:12.559 --> 00:35:13.760
<v Speaker 2>It never really stops.

714
00:35:14.079 --> 00:35:16.639
<v Speaker 1>Well, this deep dive was possible thanks to the source

715
00:35:16.679 --> 00:35:19.320
<v Speaker 1>material you sent our way, and hopefully we've pulled out

716
00:35:19.320 --> 00:35:21.559
<v Speaker 1>the most critical insights to get you thinking and applying

717
00:35:21.559 --> 00:35:23.079
<v Speaker 1>these concepts absolutely.

718
00:35:23.119 --> 00:35:25.840
<v Speaker 2>And remember, while we focused a lot on the technology,

719
00:35:25.920 --> 00:35:30.480
<v Speaker 2>the code, the configurations, secure systems also rely heavily on

720
00:35:30.519 --> 00:35:31.400
<v Speaker 2>the people involved.

721
00:35:31.960 --> 00:35:33.760
<v Speaker 1>That's a great point to end on it It raises

722
00:35:33.800 --> 00:35:35.199
<v Speaker 1>a big question for all of us, doesn't it. We

723
00:35:35.239 --> 00:35:38.280
<v Speaker 1>have all these technical controls, these best practices, but how

724
00:35:38.320 --> 00:35:41.639
<v Speaker 1>do we better bridge that gap to the human element.

725
00:35:42.119 --> 00:35:45.280
<v Speaker 1>How do we foster that culture of security awareness not

726
00:35:45.320 --> 00:35:48.840
<v Speaker 1>just among developers but everyone involved to make things truly safer.

727
00:35:49.079 --> 00:35:52.280
<v Speaker 2>Yeah, something definitely worth mulling over. How do technology and

728
00:35:52.400 --> 00:35:54.880
<v Speaker 2>people really work together for better security