WEBVTT

1
00:00:00.160 --> 00:00:03.240
<v Speaker 1>Welcome to the deep dive. You're here because you want

2
00:00:03.240 --> 00:00:05.719
<v Speaker 1>to understand the important stuff. Maybe you get those light

3
00:00:05.719 --> 00:00:08.720
<v Speaker 1>bulb moments, but without feeling like you're drowning in jargon.

4
00:00:09.000 --> 00:00:09.599
<v Speaker 2>Exactly.

5
00:00:09.800 --> 00:00:13.519
<v Speaker 1>Today we're tackling a subject that's well fascinating and also

6
00:00:13.919 --> 00:00:17.359
<v Speaker 1>increasingly vital, web haacking and penetration testing.

7
00:00:17.640 --> 00:00:20.079
<v Speaker 2>Think of it this way. We're going to explore how

8
00:00:20.120 --> 00:00:24.239
<v Speaker 2>the security of web applications gets tested, kind of like

9
00:00:24.359 --> 00:00:29.079
<v Speaker 2>understanding how a security consultant probes a building's defenses right.

10
00:00:29.000 --> 00:00:30.800
<v Speaker 1>Not to break in, but to find the weak spots

11
00:00:30.800 --> 00:00:33.560
<v Speaker 1>so they can actually be fixed precisely. And our guide

12
00:00:33.560 --> 00:00:36.759
<v Speaker 1>for this, our source material is Rafe Block and his

13
00:00:36.840 --> 00:00:41.240
<v Speaker 1>book Web Haackingarsenal dot pdf. Now this isn't just theory,

14
00:00:41.320 --> 00:00:44.439
<v Speaker 1>is it. Blog has real hands on experience.

15
00:00:44.520 --> 00:00:48.560
<v Speaker 2>He does real world security work, finding vulnerabilities, understanding the

16
00:00:48.640 --> 00:00:50.880
<v Speaker 2>threats that are actually out there right now. So the

17
00:00:50.920 --> 00:00:53.200
<v Speaker 2>book is a very practical look sort of under the

18
00:00:53.240 --> 00:00:55.920
<v Speaker 2>hood of web security. Okay, And what's really key to

19
00:00:56.000 --> 00:00:58.560
<v Speaker 2>grasp is that web security is always changing. I mean,

20
00:00:58.880 --> 00:01:02.320
<v Speaker 2>new vulnerabilities pop up constantly, attackers find new tricks.

21
00:01:02.560 --> 00:01:04.680
<v Speaker 1>Yeah, it never stands still not at all.

22
00:01:04.760 --> 00:01:07.760
<v Speaker 2>So Block's work gives us a valuable, pretty up to

23
00:01:07.840 --> 00:01:09.239
<v Speaker 2>date view on these challenges.

24
00:01:09.640 --> 00:01:12.079
<v Speaker 1>So our mission today really is to pull out the

25
00:01:12.239 --> 00:01:16.200
<v Speaker 1>essential ideas and techniques from Block's book. We want to

26
00:01:16.239 --> 00:01:19.879
<v Speaker 1>give you the listener a clearer picture of these vulnerabilities

27
00:01:19.920 --> 00:01:24.599
<v Speaker 1>and how security pros the ethical hackers actually find them. Yeah, okay,

28
00:01:24.719 --> 00:01:25.480
<v Speaker 1>let's get into it.

29
00:01:25.599 --> 00:01:28.239
<v Speaker 2>Let's do it. Let's maybe start with the absolute basics.

30
00:01:28.519 --> 00:01:33.079
<v Speaker 2>How does the web actually work? Block begins there explaining HTTP.

31
00:01:33.319 --> 00:01:36.920
<v Speaker 1>That's the foundation, right HGTP. You see it HTTP at

32
00:01:36.959 --> 00:01:40.439
<v Speaker 1>the start of web addresses. Now, one fundamental thing Block

33
00:01:40.519 --> 00:01:44.319
<v Speaker 1>points out is that HTTP is stateless. What does that

34
00:01:44.359 --> 00:01:45.079
<v Speaker 1>mean exactly?

35
00:01:45.560 --> 00:01:48.439
<v Speaker 2>Imagine you're talking to a waiter, but each time you speak,

36
00:01:48.480 --> 00:01:50.799
<v Speaker 2>it's like they've never met you before. The server doesn't

37
00:01:50.799 --> 00:01:52.760
<v Speaker 2>automatically remember your previous request.

38
00:01:52.879 --> 00:01:55.519
<v Speaker 1>Ah okay, so each request is independent.

39
00:01:55.159 --> 00:01:57.439
<v Speaker 2>Exactly, And because it's stateless, websites need a way to

40
00:01:57.480 --> 00:01:59.359
<v Speaker 2>keep track of you, right, Like when you log in.

41
00:01:59.400 --> 00:02:02.719
<v Speaker 2>That's where cookie. When you log in, the server sends

42
00:02:02.760 --> 00:02:05.359
<v Speaker 2>this tiny piece of data, the cookie, to your browser.

43
00:02:05.760 --> 00:02:08.400
<v Speaker 2>Your browser then sends it back with every request after that.

44
00:02:08.639 --> 00:02:10.919
<v Speaker 1>So the server knows, ah, it's still.

45
00:02:10.719 --> 00:02:12.960
<v Speaker 2>You exactly, it maintains that state.

46
00:02:13.319 --> 00:02:17.560
<v Speaker 1>Belloch also stresses though that standard HTTP isn't encrypted.

47
00:02:17.759 --> 00:02:20.560
<v Speaker 2>That's a huge point. It's like sending a postcard. Anyone

48
00:02:20.599 --> 00:02:23.240
<v Speaker 2>who intercepts it can potentially read it.

49
00:02:23.479 --> 00:02:26.120
<v Speaker 1>No ideal for logins or credit cards, definitely not.

50
00:02:26.439 --> 00:02:29.639
<v Speaker 2>That's why we have HTTPS. The S means secure. It

51
00:02:29.680 --> 00:02:32.919
<v Speaker 2>adds that layer of encryption, usually TLS or SSL, to

52
00:02:32.960 --> 00:02:34.199
<v Speaker 2>make the communication private.

53
00:02:34.439 --> 00:02:39.039
<v Speaker 1>Okay, so HTTP is the basic protocol, maybe insecure HDPS

54
00:02:39.080 --> 00:02:43.639
<v Speaker 1>adds the security layer. What about get, GETEE and post requests?

55
00:02:44.000 --> 00:02:45.520
<v Speaker 1>Block clarifies those.

56
00:02:45.319 --> 00:02:47.360
<v Speaker 2>Two right, So when you click a link or type

57
00:02:47.400 --> 00:02:51.360
<v Speaker 2>a URL, your browser usually sends a GETTT request. Any

58
00:02:51.400 --> 00:02:54.000
<v Speaker 2>extra bits of information like search terms often end up

59
00:02:54.039 --> 00:02:55.039
<v Speaker 2>right in the URL.

60
00:02:54.840 --> 00:02:56.479
<v Speaker 1>Itself visible in the address bar.

61
00:02:56.439 --> 00:03:00.479
<v Speaker 2>Yep visible, potentially saved in your history server logs that

62
00:03:00.520 --> 00:03:03.439
<v Speaker 2>can have privacy implications. Think about sharing a link that

63
00:03:03.520 --> 00:03:05.039
<v Speaker 2>has sensitive search terms in it.

64
00:03:05.159 --> 00:03:08.039
<v Speaker 1>Good point. You might share more than you intend. So

65
00:03:08.080 --> 00:03:09.120
<v Speaker 1>what's post Then?

66
00:03:09.400 --> 00:03:13.159
<v Speaker 2>PST sends data differently. It's in the background, in the

67
00:03:13.159 --> 00:03:16.080
<v Speaker 2>body of the request, not usually visible in the URL.

68
00:03:16.599 --> 00:03:21.120
<v Speaker 2>This is typically used for submitting forms, login details, comments,

69
00:03:21.159 --> 00:03:21.759
<v Speaker 2>that kind of thing.

70
00:03:21.840 --> 00:03:26.280
<v Speaker 1>Okay, So get shows parameters in the url PST hinds

71
00:03:26.319 --> 00:03:29.560
<v Speaker 1>them in the request body makes sense. Now, you mentioned

72
00:03:29.599 --> 00:03:34.240
<v Speaker 1>the tech behind websites is evolving beyond the classic LMP stack.

73
00:03:34.479 --> 00:03:39.560
<v Speaker 2>Yeah. Absolutely, the traditional L ANDP stack, Linux, Apache, Myseql, PHP,

74
00:03:39.719 --> 00:03:43.319
<v Speaker 2>it's still around, definitely, But Block points out the rise

75
00:03:43.360 --> 00:03:46.039
<v Speaker 2>of newer things like micro services, breaking.

76
00:03:45.800 --> 00:03:47.639
<v Speaker 1>Big applications into smaller.

77
00:03:47.280 --> 00:03:51.400
<v Speaker 2>Pieces exactly, and serverlest computing where you don't manage servers directly.

78
00:03:51.479 --> 00:03:54.560
<v Speaker 2>Plus different databases no suite types like Mango dB.

79
00:03:54.680 --> 00:03:57.159
<v Speaker 1>And these new technologies bring new security challenges.

80
00:03:57.199 --> 00:04:00.560
<v Speaker 2>They definitely change the landscape. Different potential weaknesses can emerge.

81
00:04:00.599 --> 00:04:03.039
<v Speaker 1>Okay, so we've got a basic picture of web communication.

82
00:04:03.280 --> 00:04:05.840
<v Speaker 1>Now how do people actually start looking for vulnerabilities?

83
00:04:05.879 --> 00:04:09.439
<v Speaker 2>You mentioned reconnaissance, right, intelligence gathering and enumeration. It's the

84
00:04:09.479 --> 00:04:14.120
<v Speaker 2>recon phase. Block really emphasizes how critical this is, especially.

85
00:04:13.719 --> 00:04:17.399
<v Speaker 1>You said in things like bug bounty programs where speed matters.

86
00:04:17.439 --> 00:04:21.000
<v Speaker 2>Absolutely, you need to map out the target thoroughly and quickly.

87
00:04:21.360 --> 00:04:25.000
<v Speaker 2>He breaks it down into active and passive subdomain enumeration.

88
00:04:25.360 --> 00:04:27.759
<v Speaker 1>Active versus passive. What's the difference there?

89
00:04:27.959 --> 00:04:32.519
<v Speaker 2>Active means you're directly probing the target, sending requests, trying

90
00:04:32.519 --> 00:04:34.920
<v Speaker 2>things out to see what subdomains exist.

91
00:04:34.759 --> 00:04:37.240
<v Speaker 1>Like knocking on doors kind of Yeah.

92
00:04:37.600 --> 00:04:40.680
<v Speaker 2>Passive is more about gathering info that's already out there,

93
00:04:40.720 --> 00:04:44.399
<v Speaker 2>publicly available without directly touching the target systems.

94
00:04:44.199 --> 00:04:47.360
<v Speaker 1>Like looking at public records or maps instead of knocking.

95
00:04:47.079 --> 00:04:49.800
<v Speaker 2>Precisely, and blog runs through a whole toolkit for this.

96
00:04:50.240 --> 00:04:52.839
<v Speaker 2>One of the first techniques is reverse IP lookup.

97
00:04:53.199 --> 00:04:55.720
<v Speaker 1>So you have the server's IP address, and.

98
00:04:55.720 --> 00:04:58.480
<v Speaker 2>This lookup tries to find all the domain names hosted

99
00:04:58.519 --> 00:05:02.399
<v Speaker 2>on that same server uncover hidden parts of an organization's

100
00:05:02.480 --> 00:05:03.639
<v Speaker 2>online footprint.

101
00:05:03.920 --> 00:05:05.759
<v Speaker 1>Interesting, okay, what else?

102
00:05:05.959 --> 00:05:09.639
<v Speaker 2>Port scanning yep n map is common, but Block mentions

103
00:05:09.680 --> 00:05:13.680
<v Speaker 2>masscans specifically for its speed. It rapidly checks which communication

104
00:05:13.800 --> 00:05:14.800
<v Speaker 2>ports are open on a.

105
00:05:14.759 --> 00:05:18.519
<v Speaker 1>Server, and open ports might mean running services.

106
00:05:18.360 --> 00:05:22.120
<v Speaker 2>Potentially vulnerable services. Yeah, things that might have been overlooked.

107
00:05:22.319 --> 00:05:24.480
<v Speaker 1>But an open port isn't always a web server.

108
00:05:24.360 --> 00:05:27.720
<v Speaker 2>Right, Good point. That's where a tool like httpx comes in.

109
00:05:28.040 --> 00:05:30.639
<v Speaker 2>Block explains it takes the open ports found by masscan,

110
00:05:30.759 --> 00:05:33.680
<v Speaker 2>for example, and checks which ones are actually running web

111
00:05:33.720 --> 00:05:36.319
<v Speaker 2>services HTTP or HTTPS.

112
00:05:36.439 --> 00:05:39.839
<v Speaker 1>Got it, So find open poorts quickly, then verify which

113
00:05:39.879 --> 00:05:43.240
<v Speaker 1>are web related? What about finding subdomains specifically?

114
00:05:43.399 --> 00:05:47.120
<v Speaker 2>He mentions shuffles. It uses big lists of common subdomain

115
00:05:47.199 --> 00:05:50.680
<v Speaker 2>names like blog shop dev and checks if they exist

116
00:05:50.680 --> 00:05:53.480
<v Speaker 2>for the target domain using various DNS servers.

117
00:05:53.519 --> 00:05:55.720
<v Speaker 1>Okay, trying common names, Yeah, makes sense.

118
00:05:56.000 --> 00:05:58.920
<v Speaker 2>Now here's where it gets really clever. I think passive

119
00:05:59.000 --> 00:06:00.480
<v Speaker 2>enumeration using showdown.

120
00:06:00.839 --> 00:06:04.160
<v Speaker 1>Showdown the search engine for Internet connected devices exactly.

121
00:06:04.560 --> 00:06:07.240
<v Speaker 2>Block explains how you can use the unique hash of

122
00:06:07.279 --> 00:06:08.959
<v Speaker 2>a website's fabcon.

123
00:06:08.680 --> 00:06:10.680
<v Speaker 1>The little icon in the browser tab that's the.

124
00:06:10.639 --> 00:06:14.319
<v Speaker 2>One it's unique identifier. It's hash can sometimes be used

125
00:06:14.319 --> 00:06:17.480
<v Speaker 2>to find other related subdomains that use the same icon.

126
00:06:17.639 --> 00:06:20.560
<v Speaker 1>Wow, like a digital fingerprint pretty much.

127
00:06:21.199 --> 00:06:24.959
<v Speaker 2>If two sites share that specific fabcon hash, it's a

128
00:06:25.000 --> 00:06:28.399
<v Speaker 2>decent clue they might be related. Block even shows how

129
00:06:28.399 --> 00:06:31.480
<v Speaker 2>to automate finding this with tools like CURL and Showdown's

130
00:06:31.480 --> 00:06:32.519
<v Speaker 2>own command line tool.

131
00:06:33.000 --> 00:06:35.120
<v Speaker 1>That's neat. What other passive methods?

132
00:06:35.199 --> 00:06:39.959
<v Speaker 2>Certificate transparency logs. These are public records of all SSLTLS

133
00:06:40.000 --> 00:06:43.680
<v Speaker 2>certificates issued. They list domain and subdomain names, so they're

134
00:06:43.680 --> 00:06:45.279
<v Speaker 2>a gold mine for passive discovery.

135
00:06:45.519 --> 00:06:49.319
<v Speaker 1>Ah Okay, and web archives like the Wayback Machine YEP.

136
00:06:49.639 --> 00:06:52.759
<v Speaker 2>Looking at historical versions of a site can reveal subdomains

137
00:06:52.800 --> 00:06:55.199
<v Speaker 2>that existed in the past, even if they're not live now,

138
00:06:55.279 --> 00:06:58.199
<v Speaker 2>sometimes they come back online or point to interesting things.

139
00:06:58.480 --> 00:07:01.720
<v Speaker 1>So digging through history and then there's a mass. You

140
00:07:01.759 --> 00:07:02.680
<v Speaker 1>said it's comprehensive.

141
00:07:02.800 --> 00:07:05.199
<v Speaker 2>Yeah, a mass pulls together a lot of techniques, both

142
00:07:05.279 --> 00:07:09.720
<v Speaker 2>active and passive. Block highlights its different modules, Intel for

143
00:07:09.800 --> 00:07:13.759
<v Speaker 2>gathering initial info and for the actual subdomain, searching, dB

144
00:07:13.920 --> 00:07:15.319
<v Speaker 2>for storing results.

145
00:07:15.079 --> 00:07:18.079
<v Speaker 1>VIZ for visualizing, and track right viz helps you see

146
00:07:18.079 --> 00:07:21.199
<v Speaker 1>the relationships, and track is great for monitoring changes over time.

147
00:07:21.639 --> 00:07:24.879
<v Speaker 1>Did a new subdomain appear? Did one disappear? Very useful?

148
00:07:25.360 --> 00:07:27.839
<v Speaker 1>What about finding hidden files or directories?

149
00:07:28.439 --> 00:07:33.439
<v Speaker 2>That's directory fuzzing tools like FFUF or deerbuster use wordless

150
00:07:33.680 --> 00:07:36.399
<v Speaker 2>lists of common directory and file names to guess paths

151
00:07:36.439 --> 00:07:37.199
<v Speaker 2>on the server.

152
00:07:37.240 --> 00:07:39.680
<v Speaker 1>Trying to find pages that aren't linked publicly exactly.

153
00:07:39.720 --> 00:07:44.480
<v Speaker 2>Maybe configuration files, old backups, adamin interfaces, things that could

154
00:07:44.480 --> 00:07:46.639
<v Speaker 2>hold sensitive info or vulnerabilities.

155
00:07:46.720 --> 00:07:50.079
<v Speaker 1>Okay, and you mentioned gaffer finding known URLs.

156
00:07:50.360 --> 00:07:53.279
<v Speaker 2>Yeah, gaff etches URLs for a domain from various public

157
00:07:53.319 --> 00:07:57.399
<v Speaker 2>sources like the Wayback Machine, Common crawl, etc. It's passive

158
00:07:57.439 --> 00:07:59.240
<v Speaker 2>gathering of known paths.

159
00:07:59.000 --> 00:08:01.279
<v Speaker 1>And JavaScript files. You said they can leak.

160
00:08:01.120 --> 00:08:06.120
<v Speaker 2>Info, Oh, definitely. Block stresses looking inside JavaScript developers sometimes

161
00:08:06.160 --> 00:08:10.199
<v Speaker 2>accidentally leave comments, internal API en points, maybe even secret

162
00:08:10.240 --> 00:08:13.040
<v Speaker 2>keys or subdomain names in the code. He uses a

163
00:08:13.040 --> 00:08:15.160
<v Speaker 2>PayPal example to show how this can happen.

164
00:08:15.240 --> 00:08:17.160
<v Speaker 1>Wow, just hiding in plain sight in the code.

165
00:08:17.199 --> 00:08:21.160
<v Speaker 2>Sometimes Yeah, then there's crawling or spidering. Tools like gospeitter

166
00:08:21.160 --> 00:08:24.480
<v Speaker 2>automatically follow links on a website to map out its structure.

167
00:08:24.160 --> 00:08:25.759
<v Speaker 1>Building a site map automatically.

168
00:08:26.120 --> 00:08:29.680
<v Speaker 2>Right and Bolock notes gospitter is good at parsing JavaScript too,

169
00:08:30.120 --> 00:08:33.879
<v Speaker 2>and even finding things like AWSS three buckets mentioned in the.

170
00:08:33.840 --> 00:08:36.960
<v Speaker 1>Code, which brings us to cloud stuff s three.

171
00:08:36.840 --> 00:08:41.480
<v Speaker 2>Buckets, Yeah, Amazon s three storage buckets. Block discusses how

172
00:08:41.519 --> 00:08:45.159
<v Speaker 2>misconfigured cloud storage is a common problem. If a bucket

173
00:08:45.200 --> 00:08:48.799
<v Speaker 2>is accidentally made public, it can expose huge amounts of data.

174
00:08:49.200 --> 00:08:53.279
<v Speaker 2>He points to resources like buckets dot grayhtwarfare dot com

175
00:08:53.279 --> 00:08:56.440
<v Speaker 2>for finding these leaky buckets across different cloud providers.

176
00:08:56.519 --> 00:08:58.679
<v Speaker 1>Okay, so that's the recon A lot goes into just

177
00:08:58.759 --> 00:09:02.039
<v Speaker 1>mapping things out. Now, what weaknesses are they actually looking

178
00:09:02.039 --> 00:09:05.360
<v Speaker 1>for once they have this map? Server side injection attacks.

179
00:09:05.200 --> 00:09:08.039
<v Speaker 2>Right, These are really serious because they let an attacker

180
00:09:08.159 --> 00:09:11.080
<v Speaker 2>inject code that runs on the web server itself. SQL

181
00:09:11.120 --> 00:09:13.039
<v Speaker 2>injection is the classic example.

182
00:09:12.720 --> 00:09:16.080
<v Speaker 1>SQL injection heard of. It seems bad. How does it work?

183
00:09:16.120 --> 00:09:20.000
<v Speaker 2>Basically, you inject malicious SQL database commands into input fields,

184
00:09:20.080 --> 00:09:24.039
<v Speaker 2>search boxes, log informs, even URL parameter. Sometimes, if the

185
00:09:24.080 --> 00:09:27.320
<v Speaker 2>application doesn't clean that input properly, the database might run

186
00:09:27.360 --> 00:09:28.559
<v Speaker 2>your malicious command.

187
00:09:28.360 --> 00:09:31.200
<v Speaker 1>And that lets you do what steal data.

188
00:09:30.879 --> 00:09:34.679
<v Speaker 2>Steal data, modify data, sometimes even take control of the database.

189
00:09:34.720 --> 00:09:38.159
<v Speaker 2>Server block covers different ways to exploit it. Error based,

190
00:09:38.200 --> 00:09:41.639
<v Speaker 2>where you cause errors that leak info, boolean base asking

191
00:09:41.679 --> 00:09:46.399
<v Speaker 2>true false questions, time based, making the database pause to infer.

192
00:09:46.240 --> 00:09:50.559
<v Speaker 1>Things clever, and tools like sql map help automate this massively.

193
00:09:50.679 --> 00:09:53.519
<v Speaker 2>Sql map is a powerful tool for finding and exploiting

194
00:09:53.519 --> 00:09:57.679
<v Speaker 2>sqal injection. Block also mentions an interesting angle SQL injection

195
00:09:57.919 --> 00:09:59.879
<v Speaker 2>via jawts JWTs.

196
00:10:00.080 --> 00:10:02.639
<v Speaker 1>Yeah, those json web tokens for sessions. Yeah.

197
00:10:02.759 --> 00:10:05.600
<v Speaker 2>Sometimes if the application decodes a GENWT and uses a

198
00:10:05.679 --> 00:10:08.440
<v Speaker 2>value from it directly in a database query without proper checks,

199
00:10:08.679 --> 00:10:11.039
<v Speaker 2>you could inject SQL through the jatabt payload.

200
00:10:11.240 --> 00:10:13.879
<v Speaker 1>Wow. Okay, And it's not just secle databases right no.

201
00:10:13.919 --> 00:10:17.120
<v Speaker 2>Sql right Block covers no seqal injection too, using Mango

202
00:10:17.200 --> 00:10:19.679
<v Speaker 2>dB as an example. You can use special operators like

203
00:10:19.840 --> 00:10:22.519
<v Speaker 2>two dollars for greater than in your input to trick

204
00:10:22.519 --> 00:10:24.759
<v Speaker 2>the database logic, maybe bypass a log.

205
00:10:24.559 --> 00:10:27.679
<v Speaker 1>In okay, beyond databases. Command injection.

206
00:10:27.879 --> 00:10:31.039
<v Speaker 2>This is injecting operating system commands if an application takes

207
00:10:31.120 --> 00:10:34.200
<v Speaker 2>user input and passes it directly to a system function.

208
00:10:34.039 --> 00:10:35.879
<v Speaker 1>Like exec like in no JS you mentioned.

209
00:10:36.039 --> 00:10:39.000
<v Speaker 2>Yeah, no JS exec is a common example if that

210
00:10:39.080 --> 00:10:42.559
<v Speaker 2>input isn't sanitized and to tacker could run commands directly

211
00:10:42.600 --> 00:10:46.159
<v Speaker 2>on the server's operating system. Block even quotes the official

212
00:10:46.200 --> 00:10:48.360
<v Speaker 2>no JS stocks warning against this.

213
00:10:48.720 --> 00:10:51.960
<v Speaker 1>That sounds really dangerous full server takeover.

214
00:10:51.559 --> 00:10:55.960
<v Speaker 2>Potential potentially Yes. Then there's SSTI server side.

215
00:10:55.720 --> 00:10:57.320
<v Speaker 1>Template injection gumplet injection.

216
00:10:57.440 --> 00:11:01.919
<v Speaker 2>Web frameworks often use template engines to generate HTML dynamically.

217
00:11:02.240 --> 00:11:05.240
<v Speaker 2>Think of placeholders filled with data. If an attacker can

218
00:11:05.279 --> 00:11:07.639
<v Speaker 2>inject template syntax itself.

219
00:11:07.279 --> 00:11:09.399
<v Speaker 1>Like the special characters the template engine.

220
00:11:09.200 --> 00:11:12.320
<v Speaker 2>Uses exactly, they might be able to escape the intended

221
00:11:12.360 --> 00:11:15.840
<v Speaker 2>context and run code. Block gives examples for ginga TOO

222
00:11:15.879 --> 00:11:18.919
<v Speaker 2>and MECO templates showing how you can achieve remote code

223
00:11:18.919 --> 00:11:20.399
<v Speaker 2>execution RCE.

224
00:11:20.919 --> 00:11:23.399
<v Speaker 1>RCE again seems like the ultimate goal.

225
00:11:23.480 --> 00:11:25.799
<v Speaker 2>Often it's definitely a high impact finding.

226
00:11:25.559 --> 00:11:27.519
<v Speaker 1>Okay, so those are server side. What about attacks that

227
00:11:27.519 --> 00:11:30.360
<v Speaker 1>happened in my browser? Cross site SCRIPTINGXSS. Right.

228
00:11:30.519 --> 00:11:34.559
<v Speaker 2>XSS is about injecting malicious client side scripts, usually JavaScript,

229
00:11:34.600 --> 00:11:37.200
<v Speaker 2>into a web page, which then gets executed by other

230
00:11:37.360 --> 00:11:38.399
<v Speaker 2>users browsers, so.

231
00:11:38.399 --> 00:11:41.360
<v Speaker 1>The bad code runs in the victims browser, not the server.

232
00:11:41.759 --> 00:11:46.279
<v Speaker 2>Correct block explains DOM based XSS, where the vulnerability lies

233
00:11:46.480 --> 00:11:49.639
<v Speaker 2>in the page's own JavaScript code rather than the server code.

234
00:11:49.720 --> 00:11:52.440
<v Speaker 2>He talked about sources where malicious data comes from, like

235
00:11:52.480 --> 00:11:54.879
<v Speaker 2>the URL and syncs where that data is used on

236
00:11:55.000 --> 00:11:56.879
<v Speaker 2>safely causing script execution.

237
00:11:57.240 --> 00:11:59.799
<v Speaker 1>Okay, sources and sinks in the browser's dom.

238
00:12:00.240 --> 00:12:03.840
<v Speaker 2>He also touches on client side template injections similar to SSTI,

239
00:12:03.960 --> 00:12:06.679
<v Speaker 2>but happening in JavaScript frameworks in the browser, and he

240
00:12:06.840 --> 00:12:11.240
<v Speaker 2>details XSS risks in frameworks like Angular JS and React JS.

241
00:12:11.440 --> 00:12:14.159
<v Speaker 1>Seems like XSS can pop up in unexpected places too.

242
00:12:14.360 --> 00:12:18.480
<v Speaker 2>File uploads, yeah, block mentions uploading files like SVG scalable

243
00:12:18.559 --> 00:12:21.879
<v Speaker 2>vector graphics. They look like images, but they're XML based

244
00:12:21.919 --> 00:12:25.720
<v Speaker 2>and can contain executable script content or even hiding scripts

245
00:12:25.720 --> 00:12:26.759
<v Speaker 2>and image metadata.

246
00:12:27.080 --> 00:12:30.080
<v Speaker 1>Sneaky and what can attackers do with EXSS?

247
00:12:30.200 --> 00:12:33.840
<v Speaker 2>A lot? Unfortunately, steal session cookies to hijack accounts, readerupt

248
00:12:33.879 --> 00:12:37.480
<v Speaker 2>users to fit login pages, phishing, capture keystrokes.

249
00:12:36.960 --> 00:12:39.159
<v Speaker 1>To pretty serious consequences. Are their defenses.

250
00:12:39.639 --> 00:12:43.320
<v Speaker 2>CSP Content Security policy. Yes, CSP is a browser mechanism

251
00:12:43.320 --> 00:12:46.679
<v Speaker 2>to control what resources, scripts, styles, etc. Page is allowed

252
00:12:46.679 --> 00:12:47.799
<v Speaker 2>to load. It's a major.

253
00:12:47.559 --> 00:12:50.279
<v Speaker 1>Defense, but attackers try to bypass it.

254
00:12:50.480 --> 00:12:55.799
<v Speaker 2>Always block lists, common bypasses, exploiting unsafe inline or unsafe

255
00:12:55.840 --> 00:12:59.519
<v Speaker 2>evil directives, finding vulnerable third party end points allowed by

256
00:12:59.559 --> 00:13:03.960
<v Speaker 2>the CSP, using data ris if allowed XSS via JavaScript

257
00:13:03.960 --> 00:13:07.600
<v Speaker 2>file uploads again, even exploiting browser bugs. Sometimes it's a

258
00:13:07.639 --> 00:13:08.399
<v Speaker 2>cat and mouse game.

259
00:13:08.480 --> 00:13:10.639
<v Speaker 1>He also mentions the same Origin policy SOP.

260
00:13:10.960 --> 00:13:14.759
<v Speaker 2>SOP is fundamental. It stops scripts from one website accessing

261
00:13:14.840 --> 00:13:18.000
<v Speaker 2>data or properties of another website a different origin, but

262
00:13:18.039 --> 00:13:21.159
<v Speaker 2>block notes ways. It can sometimes be relapsed or bypassed,

263
00:13:21.399 --> 00:13:23.000
<v Speaker 2>like using document dot domain.

264
00:13:23.399 --> 00:13:26.320
<v Speaker 1>Okay, now this next one sounds really interesting dom clobbering.

265
00:13:26.559 --> 00:13:30.039
<v Speaker 2>Yeah, this is clever. You use HTML elements, specifically their

266
00:13:30.039 --> 00:13:33.440
<v Speaker 2>ID or name attributes, to create global JavaScript variables on

267
00:13:33.480 --> 00:13:36.960
<v Speaker 2>the page that can overwrite existing legitimate variables or functions.

268
00:13:36.960 --> 00:13:37.639
<v Speaker 1>How does that work?

269
00:13:37.919 --> 00:13:40.519
<v Speaker 2>If you have an element like input eyed some variable

270
00:13:40.600 --> 00:13:43.799
<v Speaker 2>and some browsers window dot some variable might now refer

271
00:13:43.879 --> 00:13:46.879
<v Speaker 2>to that input element. Attackers use this to break security

272
00:13:46.960 --> 00:13:50.480
<v Speaker 2>checks or manipulate page logic Block gives examples of bypassing

273
00:13:50.480 --> 00:13:53.480
<v Speaker 2>filters or even changing document dot cookie.

274
00:13:53.080 --> 00:13:58.000
<v Speaker 1>Wow overwriting variables with HTML tags and mutation.

275
00:13:58.080 --> 00:14:02.039
<v Speaker 2>XSS MXSS is another advanced one. It happens when the

276
00:14:02.039 --> 00:14:05.480
<v Speaker 2>browser tries to fix broken or weird HTML, and in

277
00:14:05.519 --> 00:14:09.759
<v Speaker 2>the process of mutating it accidentally creates an EXSS vulnerability

278
00:14:09.879 --> 00:14:13.039
<v Speaker 2>that wasn't in the original markup. He mentions Mozilla's Bleach

279
00:14:13.159 --> 00:14:15.320
<v Speaker 2>library for sanitizing HTML to prevent this.

280
00:14:15.679 --> 00:14:18.120
<v Speaker 1>Okay, lots of ways to attack the client side. What

281
00:14:18.200 --> 00:14:21.039
<v Speaker 1>about CSRF Cross site request forgery.

282
00:14:21.440 --> 00:14:24.519
<v Speaker 2>CSRF tricks your logged in browser into sending a request

283
00:14:24.600 --> 00:14:27.480
<v Speaker 2>to a website you're authenticated to, but without your intention,

284
00:14:27.759 --> 00:14:31.600
<v Speaker 2>like making you unknowingly change your email address or transfer funds.

285
00:14:31.759 --> 00:14:32.519
<v Speaker 1>How did that happen?

286
00:14:32.559 --> 00:14:35.080
<v Speaker 2>An attacker might embed a hidden image, tag or form

287
00:14:35.120 --> 00:14:37.480
<v Speaker 2>on a malicious site or in an email that points

288
00:14:37.519 --> 00:14:39.840
<v Speaker 2>to an action you arel on the target site. When

289
00:14:39.840 --> 00:14:42.879
<v Speaker 2>your browser loads it, it automatically includes your cookies, making the

290
00:14:42.919 --> 00:14:44.120
<v Speaker 2>request seem legitimate.

291
00:14:44.200 --> 00:14:46.039
<v Speaker 1>Yikes, so the site thinks I wanted to do that

292
00:14:46.080 --> 00:14:47.080
<v Speaker 1>action exactly.

293
00:14:47.440 --> 00:14:50.240
<v Speaker 2>Bollock mentions tools like oh ask, ZAPPP which can help

294
00:14:50.320 --> 00:14:53.120
<v Speaker 2>generate proof of concepts CSRF attacks for testing.

295
00:14:53.240 --> 00:14:54.720
<v Speaker 1>Are the defenses tokens.

296
00:14:55.000 --> 00:14:58.840
<v Speaker 2>Yes, the main defense is using unpredictable unique tokens. For

297
00:14:58.919 --> 00:15:02.480
<v Speaker 2>each session or request, the server checks for this token

298
00:15:02.559 --> 00:15:05.879
<v Speaker 2>to ensure the request was intentionally initiated by the user

299
00:15:06.000 --> 00:15:07.039
<v Speaker 2>on the site itself.

300
00:15:07.320 --> 00:15:09.440
<v Speaker 1>But attackers try to bypass these tokens too.

301
00:15:09.519 --> 00:15:12.360
<v Speaker 2>He do maybe by exploiting how the site checks the

302
00:15:12.440 --> 00:15:16.360
<v Speaker 2>referra or origin headers, or if token validation is inconsistent.

303
00:15:16.960 --> 00:15:21.120
<v Speaker 2>Block also discusses the same site cookie attribute another defense layer,

304
00:15:21.480 --> 00:15:24.399
<v Speaker 2>in ways it might be bypassed, perhaps through XSS or

305
00:15:24.440 --> 00:15:25.759
<v Speaker 2>clever subdomain tricks.

306
00:15:25.879 --> 00:15:30.080
<v Speaker 1>Okay, let's move to attacking the file system itself directory traversal.

307
00:15:30.360 --> 00:15:33.720
<v Speaker 2>This is about accessing files outside of the intended web

308
00:15:33.799 --> 00:15:38.720
<v Speaker 2>route directory by manipulating filepaths, often using sequences.

309
00:15:38.159 --> 00:15:40.080
<v Speaker 1>The go up one directory command right.

310
00:15:40.320 --> 00:15:42.840
<v Speaker 2>An attacker might try to read sensitive files like EXCTA

311
00:15:42.879 --> 00:15:46.600
<v Speaker 2>pass on Linux or configuration files. Block mentions using curl

312
00:15:46.639 --> 00:15:49.440
<v Speaker 2>path as is to make sure the debt isn't normalized

313
00:15:49.480 --> 00:15:52.080
<v Speaker 2>away by the tool itself and it's much worse if

314
00:15:52.080 --> 00:15:53.799
<v Speaker 2>the web app runs with high privileges.

315
00:15:53.919 --> 00:15:56.399
<v Speaker 1>Okay, reading files, what about creating files?

316
00:15:56.799 --> 00:16:00.279
<v Speaker 2>Arbitrary file creation? If a vulnerability allows an attack to

317
00:16:00.279 --> 00:16:02.480
<v Speaker 2>specify the name and content of a file that gets

318
00:16:02.480 --> 00:16:05.200
<v Speaker 2>saved on the server, that's really bad. They could write

319
00:16:05.200 --> 00:16:07.159
<v Speaker 2>webshells or other malicious code.

320
00:16:07.240 --> 00:16:09.879
<v Speaker 1>And local file inclusion LFI.

321
00:16:09.720 --> 00:16:12.279
<v Speaker 2>LiFi is similar to traversal, but instead of just reading

322
00:16:12.279 --> 00:16:15.799
<v Speaker 2>a file, the attacker tricks the application into including and

323
00:16:15.840 --> 00:16:20.200
<v Speaker 2>potentially executing a local files content block uses PHP's read

324
00:16:20.240 --> 00:16:23.480
<v Speaker 2>file function as an example, but include a require functions

325
00:16:23.519 --> 00:16:25.559
<v Speaker 2>can sometimes lead to code execution too.

326
00:16:25.759 --> 00:16:29.720
<v Speaker 1>Okay, filesystem access is clearly bad. What about file uploads?

327
00:16:29.919 --> 00:16:32.240
<v Speaker 1>We touched on SPGs, but are there other risks?

328
00:16:32.519 --> 00:16:35.759
<v Speaker 2>Huge risks. Applications often try to restrict uploads to certain

329
00:16:35.759 --> 00:16:38.919
<v Speaker 2>file types like images only, but attackers try to bypass

330
00:16:38.960 --> 00:16:42.279
<v Speaker 2>these checks by manipulating the mie type reported by the

331
00:16:42.279 --> 00:16:45.039
<v Speaker 2>browser or the magic bytes, the first few bytes that

332
00:16:45.080 --> 00:16:47.759
<v Speaker 2>identify a file type. The block gives a great example

333
00:16:48.039 --> 00:16:51.919
<v Speaker 2>embedding PHP code into an image's metadata using exit tool.

334
00:16:52.080 --> 00:16:54.600
<v Speaker 1>So if file looks like a normal jpeg, passes.

335
00:16:54.279 --> 00:16:57.000
<v Speaker 2>The checks exactly, but if the attacker can later get

336
00:16:57.000 --> 00:16:59.919
<v Speaker 2>the server to execute that file somehow, maybe through a

337
00:17:00.279 --> 00:17:03.879
<v Speaker 2>LFI vulnerability, or if the server misconfigures how it handles

338
00:17:03.879 --> 00:17:06.960
<v Speaker 2>certain image types, the embedded PHP code.

339
00:17:06.839 --> 00:17:11.680
<v Speaker 1>Runs GOTE execution via image upload clever. Okay, let's switch

340
00:17:11.680 --> 00:17:13.240
<v Speaker 1>to authentication and authorization.

341
00:17:13.759 --> 00:17:18.119
<v Speaker 2>Big area, absolutely critical. Authentication is who are you? Authorization

342
00:17:18.359 --> 00:17:19.559
<v Speaker 2>is what are you allowed to do?

343
00:17:20.000 --> 00:17:24.240
<v Speaker 1>So? Authentication attacks first username enumeration, trying.

344
00:17:23.960 --> 00:17:27.680
<v Speaker 2>To figure out valid usernames. Sometimes applications give slightly different

345
00:17:27.720 --> 00:17:31.359
<v Speaker 2>error messages for user not found versus wrong password, or

346
00:17:31.400 --> 00:17:34.440
<v Speaker 2>maybe the response time is subtly different. Attackers use these clues.

347
00:17:34.519 --> 00:17:36.799
<v Speaker 1>Okay, then brute force and dictionary.

348
00:17:36.359 --> 00:17:40.480
<v Speaker 2>Attacks just trying lots of passwords against known or guest usernames.

349
00:17:40.920 --> 00:17:44.359
<v Speaker 2>Block mentions using tools like wifas, especially against things like

350
00:17:44.519 --> 00:17:46.440
<v Speaker 2>HTTP basic authentication pop.

351
00:17:46.359 --> 00:17:50.400
<v Speaker 1>Up boxes, and bypassing log informs like using PUT instead

352
00:17:50.440 --> 00:17:50.880
<v Speaker 1>of PSD.

353
00:17:51.319 --> 00:17:55.400
<v Speaker 2>Yeah, sometimes developers only protect against the expected post request,

354
00:17:55.680 --> 00:17:59.880
<v Speaker 2>leaving other HTTP methods like put potentially vulnerable to bypass

355
00:18:00.039 --> 00:18:03.920
<v Speaker 2>log in checks. He also mentions attacking account lockout policies,

356
00:18:03.960 --> 00:18:06.240
<v Speaker 2>trying to bypass them or maybe even use them to

357
00:18:06.359 --> 00:18:08.119
<v Speaker 2>lock out legitimate users.

358
00:18:08.039 --> 00:18:11.160
<v Speaker 1>And kpchas those prove your human.

359
00:18:10.920 --> 00:18:13.880
<v Speaker 2>Tests they can sometimes be beaten. A lock provides a

360
00:18:13.920 --> 00:18:18.240
<v Speaker 2>whole process using ocr optical character recognition with Tesseract. He

361
00:18:18.319 --> 00:18:21.960
<v Speaker 2>shows how to use Selenium to automate grabbing the keytcch

362
00:18:22.079 --> 00:18:25.039
<v Speaker 2>image and feeding it to Tesseract to read the characters.

363
00:18:25.359 --> 00:18:29.799
<v Speaker 1>So automating the kptchase solving. Wow. What about password resets?

364
00:18:30.039 --> 00:18:34.079
<v Speaker 2>Abusing forgot password functionality is common? Maybe the reset tokens

365
00:18:34.079 --> 00:18:37.640
<v Speaker 2>sent via email are predictable or password reset link poisoning

366
00:18:37.680 --> 00:18:40.440
<v Speaker 2>tricking the application into generating a reset link that points

367
00:18:40.480 --> 00:18:43.359
<v Speaker 2>to an attacker controlled server by manipulating the host header

368
00:18:43.359 --> 00:18:44.039
<v Speaker 2>in the request.

369
00:18:44.160 --> 00:18:46.319
<v Speaker 1>Okay, so lots of ways to attack the login process.

370
00:18:46.319 --> 00:18:48.599
<v Speaker 1>What about after log in authorization attacks?

371
00:18:48.799 --> 00:18:51.000
<v Speaker 2>This is about doing things you shouldn't be allowed to do.

372
00:18:51.279 --> 00:18:54.039
<v Speaker 2>Privileged escalation is the big one. A normal user gaining

373
00:18:54.079 --> 00:18:56.680
<v Speaker 2>admin power is due to weak access controls.

374
00:18:56.519 --> 00:18:58.839
<v Speaker 1>Or idoor insecure direct object.

375
00:18:58.559 --> 00:19:01.160
<v Speaker 2>References right where you can act as someone else's data

376
00:19:01.200 --> 00:19:03.559
<v Speaker 2>just by changing an ID number in the URL like

377
00:19:03.799 --> 00:19:06.400
<v Speaker 2>viewprofile dot PHP, dot user AD one two three to

378
00:19:06.480 --> 00:19:10.000
<v Speaker 2>user AD one to four. Also general web parameter tampering,

379
00:19:10.160 --> 00:19:14.000
<v Speaker 2>changing hidden form fields or other parameters to gain advantages.

380
00:19:13.480 --> 00:19:17.000
<v Speaker 1>You mentioned attacking JWTs earlier with c clay, but other

381
00:19:17.119 --> 00:19:17.720
<v Speaker 1>attacks too.

382
00:19:17.920 --> 00:19:20.920
<v Speaker 2>Yes, trying to crack the secret key used to sign

383
00:19:20.920 --> 00:19:25.559
<v Speaker 2>the JWT using tools like hashcat or the alg none attack,

384
00:19:25.680 --> 00:19:29.119
<v Speaker 2>changing the algorithm header to none and removing the signature,

385
00:19:29.400 --> 00:19:32.440
<v Speaker 2>hoping the server blindly trusts the payload if it sees none.

386
00:19:32.559 --> 00:19:33.599
<v Speaker 1>This seems like a bad oversight.

387
00:19:33.640 --> 00:19:36.400
<v Speaker 2>If that works, it definitely is. He also covers attacking

388
00:19:36.480 --> 00:19:38.720
<v Speaker 2>o F two point zero, often used for login with

389
00:19:38.759 --> 00:19:42.279
<v Speaker 2>Google Facebook. Attackers might try to steal access tokens by

390
00:19:42.319 --> 00:19:45.079
<v Speaker 2>manipulating the redirectory parameter to send the token to their

391
00:19:45.119 --> 00:19:45.720
<v Speaker 2>own site.

392
00:19:45.799 --> 00:19:49.279
<v Speaker 1>Okay and salmonel another login standard.

393
00:19:49.359 --> 00:19:52.440
<v Speaker 2>Similar issues tampering with the samuel response sent from the

394
00:19:52.480 --> 00:19:55.960
<v Speaker 2>identity provider back to the application, or signature exclusion attacks

395
00:19:56.119 --> 00:19:58.039
<v Speaker 2>similar to the JWT nun attack.

396
00:19:58.200 --> 00:20:01.240
<v Speaker 1>What about multi factor authentication MFA.

397
00:20:00.799 --> 00:20:04.119
<v Speaker 2>Can sometimes be bypassed, maybe the one time password OTP

398
00:20:04.279 --> 00:20:07.720
<v Speaker 2>system doesn't have rate limiting, allowing an attacker to quickly

399
00:20:07.759 --> 00:20:12.480
<v Speaker 2>brute force the code. And webcache deception is another interesting one,

400
00:20:12.720 --> 00:20:16.440
<v Speaker 2>tricking a webcache like a CDN into storing a sensitive

401
00:20:16.680 --> 00:20:20.559
<v Speaker 2>user specific page under a generic URL. The next user

402
00:20:20.559 --> 00:20:23.680
<v Speaker 2>who requests that generic URL gets served the previous user's

403
00:20:23.680 --> 00:20:26.079
<v Speaker 2>sensitive page from the cash ouch.

404
00:20:26.359 --> 00:20:30.240
<v Speaker 1>Okay, moving into a release specific area. Business logic flaws.

405
00:20:30.400 --> 00:20:34.079
<v Speaker 2>Yeah, these aren't standard technical bugs like SQL or XSS.

406
00:20:34.359 --> 00:20:37.680
<v Speaker 2>Their flaws in the application's intended logic how it's supposed

407
00:20:37.720 --> 00:20:39.720
<v Speaker 2>to work, but in a way that can be abused.

408
00:20:40.000 --> 00:20:41.400
<v Speaker 1>Examples the blow.

409
00:20:41.240 --> 00:20:44.240
<v Speaker 2>Gives several, maybe reusing a session id to manipulate a

410
00:20:44.279 --> 00:20:49.079
<v Speaker 2>digital wallet balance, or finding ways to duplicate transactions, exploiting

411
00:20:49.119 --> 00:20:52.640
<v Speaker 2>badly designed validation rules like getting infinite bonuses from a

412
00:20:52.640 --> 00:20:54.160
<v Speaker 2>self referral program.

413
00:20:53.880 --> 00:20:56.839
<v Speaker 1>So gaming this system's own rules exactly.

414
00:20:56.599 --> 00:20:59.680
<v Speaker 2>Or exploiting top up features to steal other user's balances

415
00:21:00.039 --> 00:21:03.519
<v Speaker 2>bypassing credit limits, changing shopping card items or prices, improperly

416
00:21:03.680 --> 00:21:07.119
<v Speaker 2>getting around loan amount restrictions, finding ways to get unlimited

417
00:21:07.119 --> 00:21:07.960
<v Speaker 2>wallet balances.

418
00:21:08.000 --> 00:21:10.960
<v Speaker 1>Again, it seems wallet balances are a recurring theme.

419
00:21:11.200 --> 00:21:14.200
<v Speaker 2>Money is always a target. He also covers race conditions.

420
00:21:14.319 --> 00:21:16.559
<v Speaker 1>Race conditions we're timing matters right.

421
00:21:16.519 --> 00:21:18.799
<v Speaker 2>When the outcome depends on the sequence or timing of

422
00:21:18.880 --> 00:21:23.079
<v Speaker 2>multiple threads or processes, for example, adding multiple items to

423
00:21:23.119 --> 00:21:26.640
<v Speaker 2>a cart simultaneously to exploit a pricing calculation bug, or

424
00:21:26.680 --> 00:21:29.920
<v Speaker 2>abusing an invitation system by sending multiple requests at once.

425
00:21:30.599 --> 00:21:33.400
<v Speaker 2>The lock even includes a Python script to help test

426
00:21:33.440 --> 00:21:33.799
<v Speaker 2>for these.

427
00:21:34.160 --> 00:21:39.240
<v Speaker 1>Okay, very application specific flaws. Next up, xx SSRF and

428
00:21:39.400 --> 00:21:40.319
<v Speaker 1>request smuggling.

429
00:21:40.519 --> 00:21:44.680
<v Speaker 2>Three more heavy hitters. XXSE is XML external.

430
00:21:44.279 --> 00:21:46.839
<v Speaker 1>Entity injection XML data processing. Right.

431
00:21:47.119 --> 00:21:50.079
<v Speaker 2>If an application parses XML input from users and allows

432
00:21:50.119 --> 00:21:52.880
<v Speaker 2>external entities, an attacker can define an entity that points

433
00:21:52.920 --> 00:21:56.000
<v Speaker 2>to a local file on the server like etc exps route.

434
00:21:56.279 --> 00:21:59.599
<v Speaker 2>When the XML parser resolves this entity, it reads the file.

435
00:22:00.079 --> 00:22:02.880
<v Speaker 1>So reading server files via XML can lead.

436
00:22:02.759 --> 00:22:06.319
<v Speaker 2>To RCE, sometimes yes, depending on the parser and server configuration.

437
00:22:06.680 --> 00:22:08.519
<v Speaker 1>SSRF server side request forgery.

438
00:22:08.759 --> 00:22:11.160
<v Speaker 2>This is where you trick the server into making requests

439
00:22:11.200 --> 00:22:14.480
<v Speaker 2>on your behalf. The vulnerable application makes a request to

440
00:22:14.519 --> 00:22:17.319
<v Speaker 2>an internal service within the network, or even an external

441
00:22:17.359 --> 00:22:19.599
<v Speaker 2>site that the attacker couldn't reach directly.

442
00:22:19.680 --> 00:22:20.400
<v Speaker 1>Why is that bad?

443
00:22:20.920 --> 00:22:24.480
<v Speaker 2>You can scan internal networks, access internal admin panels, or

444
00:22:24.480 --> 00:22:28.000
<v Speaker 2>even chain it with other vulnerabilities. Bulock gives an example

445
00:22:28.000 --> 00:22:30.880
<v Speaker 2>of using SSRF to talk to an internal REDTIS service

446
00:22:30.960 --> 00:22:34.720
<v Speaker 2>and gain RCE. He includes a Python payload script for that.

447
00:22:35.000 --> 00:22:38.519
<v Speaker 1>Okay, making the server attack itself or its neighbors and

448
00:22:39.880 --> 00:22:40.759
<v Speaker 1>request smuggling.

449
00:22:40.920 --> 00:22:44.759
<v Speaker 2>This one's complex. It exploits inconsistencies in how different servers

450
00:22:44.880 --> 00:22:47.279
<v Speaker 2>like a front end proxy and a back end application

451
00:22:47.400 --> 00:22:51.880
<v Speaker 2>server interpret HTTP request boundaries, especially with content length and

452
00:22:51.880 --> 00:22:55.759
<v Speaker 2>transfer encoding headers. It allows attackers to smuggle a second

453
00:22:55.880 --> 00:22:58.599
<v Speaker 2>malicious request hidden inside a seemingly normal one.

454
00:22:58.640 --> 00:23:01.480
<v Speaker 1>Tricky stuff. How about insecure de serialization.

455
00:23:01.880 --> 00:23:05.839
<v Speaker 2>This happens when an application takes serialized data data converted

456
00:23:05.839 --> 00:23:08.920
<v Speaker 2>into a format for storage or transmission, and converts it

457
00:23:08.960 --> 00:23:11.839
<v Speaker 2>back into an object in memory without proper safety checks.

458
00:23:11.920 --> 00:23:16.200
<v Speaker 1>Serialized data from where user input often yeah, or.

459
00:23:16.160 --> 00:23:21.000
<v Speaker 2>From cookies parameters. If an attacker controls that serialized data,

460
00:23:21.079 --> 00:23:24.240
<v Speaker 2>they can potentially craft malicious objects that execute code when

461
00:23:24.240 --> 00:23:28.000
<v Speaker 2>they're de serialized. Example, a Lock dives deep into PHP

462
00:23:28.160 --> 00:23:33.680
<v Speaker 2>object injection, explaining serialize and unserialized and PHP's magic methods

463
00:23:33.680 --> 00:23:37.119
<v Speaker 2>that run automatically during object creation or destruction. He gives

464
00:23:37.119 --> 00:23:40.680
<v Speaker 2>a file creator class example and mentions a real sugar

465
00:23:40.720 --> 00:23:41.799
<v Speaker 2>CRM vulnerability.

466
00:23:41.839 --> 00:23:43.720
<v Speaker 1>No get Php. What about other languages?

467
00:23:43.839 --> 00:23:47.119
<v Speaker 2>He briefly covers dot Net, mentioning binary formatter and ASP,

468
00:23:47.240 --> 00:23:50.440
<v Speaker 2>dot Net view state, and tools like whyso serial and

469
00:23:50.519 --> 00:23:55.279
<v Speaker 2>blacklist three and Java insecurity serialization Java do big time.

470
00:23:55.440 --> 00:23:58.519
<v Speaker 2>He explains Java's read object and write object, the concept

471
00:23:58.559 --> 00:24:01.279
<v Speaker 2>of gadget chains, sequences of classes that can be abused

472
00:24:01.319 --> 00:24:04.799
<v Speaker 2>during the serialization, libraries like Apache Commons collections that often

473
00:24:04.839 --> 00:24:07.920
<v Speaker 2>contain useful gadgets, and again the y serial tool for

474
00:24:07.960 --> 00:24:08.920
<v Speaker 2>generating payloads.

475
00:24:09.200 --> 00:24:12.359
<v Speaker 1>So de serializing untrusted data is dangerous across.

476
00:24:12.160 --> 00:24:15.720
<v Speaker 2>Languages, very dangerous. Always validate or avoid it if possible.

477
00:24:15.799 --> 00:24:19.359
<v Speaker 1>Okay. Let's pivot to testing specific types of services, web

478
00:24:19.400 --> 00:24:21.200
<v Speaker 1>services and cloud services.

479
00:24:21.440 --> 00:24:27.160
<v Speaker 2>Right Block covers SOAP first, simple object access protocol, older style.

480
00:24:26.880 --> 00:24:29.000
<v Speaker 1>Web service REXML based right YEP.

481
00:24:29.079 --> 00:24:33.160
<v Speaker 2>Envelope header body structure. He talks about finding the WSDL

482
00:24:33.200 --> 00:24:36.839
<v Speaker 2>file which describes the service and potentially invoking hidden methods

483
00:24:36.960 --> 00:24:38.839
<v Speaker 2>not listed in the WSDL and.

484
00:24:38.839 --> 00:24:40.920
<v Speaker 1>Rest APIs more common now.

485
00:24:40.880 --> 00:24:45.240
<v Speaker 2>Much more common, representational state transfer, more of an architectural

486
00:24:45.279 --> 00:24:49.759
<v Speaker 2>style than a strict protocol. Block discusses finding endpoints using

487
00:24:49.759 --> 00:24:52.599
<v Speaker 2>tools and looking for common descriptor files like swagger, dot

488
00:24:52.680 --> 00:24:54.799
<v Speaker 2>json or open api specs.

489
00:24:55.000 --> 00:24:57.039
<v Speaker 1>GRAPHQL. The query language for.

490
00:24:57.000 --> 00:24:59.359
<v Speaker 2>APIs yeah, graph cuil is different again, usually just a

491
00:24:59.400 --> 00:25:02.440
<v Speaker 2>single graphere endpoint where you send queries. He mentions tools

492
00:25:02.440 --> 00:25:04.640
<v Speaker 2>like all tear for crafting queries and the importance of

493
00:25:04.680 --> 00:25:07.720
<v Speaker 2>introspection queries which ask the API to describe its own

494
00:25:07.759 --> 00:25:08.839
<v Speaker 2>structure or schema.

495
00:25:08.960 --> 00:25:11.960
<v Speaker 1>Okay, and serverless functions as a service.

496
00:25:11.759 --> 00:25:15.279
<v Speaker 2>Like AWS lambda or azure functions. Block explains key features,

497
00:25:15.480 --> 00:25:19.319
<v Speaker 2>ATI Gateway's routing, requests, the event driven nature, cost savings.

498
00:25:19.440 --> 00:25:21.720
<v Speaker 2>He gives a no JS lambda example and then shows

499
00:25:21.759 --> 00:25:25.039
<v Speaker 2>a vulnerable one that accidentally exposes AWS credential ouch.

500
00:25:25.240 --> 00:25:26.839
<v Speaker 1>Can they have standard vulnerabilities too?

501
00:25:27.160 --> 00:25:31.880
<v Speaker 2>Absolutely? He highlights command injection in serverleist functions using OOS

502
00:25:31.880 --> 00:25:34.680
<v Speaker 2>serveralist code as a learning resource. Just because it's serveralist

503
00:25:34.680 --> 00:25:36.079
<v Speaker 2>doesn't mean it's automatically secure.

504
00:25:36.359 --> 00:25:39.400
<v Speaker 1>Good point. Now, what about newer HTML five features? Do

505
00:25:39.480 --> 00:25:40.519
<v Speaker 1>they introduce risks?

506
00:25:40.640 --> 00:25:44.559
<v Speaker 2>They can? Yeah? The block covers cores, cross origin resource sharing,

507
00:25:45.000 --> 00:25:49.039
<v Speaker 2>misconfiguring cores headers can weaken the same origin policy, potentially

508
00:25:49.119 --> 00:25:51.359
<v Speaker 2>enabling attacks like DOMXSS.

509
00:25:51.559 --> 00:25:54.640
<v Speaker 1>Okay. Web storage global storage session.

510
00:25:54.400 --> 00:25:57.559
<v Speaker 2>Storage convenient for storing data in the browser, but risky

511
00:25:57.680 --> 00:26:00.960
<v Speaker 2>if you store sensitive info there. Unlike cookies, there's no

512
00:26:01.119 --> 00:26:04.400
<v Speaker 2>built in HTTP only flag, so if an attacker gets EXSS,

513
00:26:04.440 --> 00:26:07.359
<v Speaker 2>they can easily read anything in web storage, potentially stealing

514
00:26:07.400 --> 00:26:08.559
<v Speaker 2>session data stored there.

515
00:26:08.559 --> 00:26:10.920
<v Speaker 1>Index DP the browser database.

516
00:26:10.960 --> 00:26:13.559
<v Speaker 2>Similar risks it's a client side database. If an attacker

517
00:26:13.640 --> 00:26:16.640
<v Speaker 2>can inject malicious data into it, maybe via EXSS, and

518
00:26:16.680 --> 00:26:19.440
<v Speaker 2>that data is later read and used unsafely by the application,

519
00:26:19.759 --> 00:26:23.079
<v Speaker 2>it can lead to stored DOM EXSS or second order EXSS.

520
00:26:23.119 --> 00:26:25.200
<v Speaker 1>Web messaging post message.

521
00:26:24.960 --> 00:26:28.880
<v Speaker 2>Use for communication between different windows or frames. The key

522
00:26:28.960 --> 00:26:31.359
<v Speaker 2>vulnerability here is failing to validate the origin of the

523
00:26:31.400 --> 00:26:35.680
<v Speaker 2>message center. If you accept messages from anywhere, an attacker's

524
00:26:35.720 --> 00:26:39.480
<v Speaker 2>malicious page could send messages to your app, potentially triggering

525
00:26:39.759 --> 00:26:44.160
<v Speaker 2>DOM EXSS web workers for background JavaScript they run scripts

526
00:26:44.160 --> 00:26:47.680
<v Speaker 2>in the background. Baylock notes potential for denial of service

527
00:26:48.039 --> 00:26:51.279
<v Speaker 2>don DOM by spawning too many workers or even using

528
00:26:51.319 --> 00:26:54.759
<v Speaker 2>them for distributed tasks like password cracking, offloading work to

529
00:26:54.799 --> 00:26:55.559
<v Speaker 2>the user's.

530
00:26:55.279 --> 00:26:56.599
<v Speaker 1>Browser, and clickjacking.

531
00:26:56.720 --> 00:26:59.720
<v Speaker 2>That's tricking a user into clicking something they didn't intend to,

532
00:27:00.039 --> 00:27:02.680
<v Speaker 2>often by loading the target site in a transparent iframe

533
00:27:02.759 --> 00:27:06.000
<v Speaker 2>overlaid on top of something else. Defenses include the x

534
00:27:06.039 --> 00:27:09.119
<v Speaker 2>frame options header or the frame ancestors directive. In csp

535
00:27:09.720 --> 00:27:11.480
<v Speaker 2>UI redressing is a similar concept.

536
00:27:11.519 --> 00:27:14.480
<v Speaker 1>Okay, a lot of potential pitfalls with HTML five now

537
00:27:14.599 --> 00:27:19.079
<v Speaker 1>Web application firewalls low BFS. They're meant to stop attacks.

538
00:27:18.799 --> 00:27:21.160
<v Speaker 2>Right they are dallyfs sit in front of web apps

539
00:27:21.200 --> 00:27:23.799
<v Speaker 2>and try to filter out malicious requests based on known

540
00:27:23.839 --> 00:27:26.400
<v Speaker 2>patterns for attacks like cqixss, etc.

541
00:27:26.799 --> 00:27:29.039
<v Speaker 1>But pentesters need to get around them first.

542
00:27:29.119 --> 00:27:32.200
<v Speaker 2>You try to figure out which WF is being used, fingerprinting,

543
00:27:33.039 --> 00:27:37.359
<v Speaker 2>block mentions, looking at HTTP headers, cookie values, specific cookie

544
00:27:37.400 --> 00:27:39.960
<v Speaker 2>set by products like Citrix, NetScaler or Barracuda.

545
00:27:40.039 --> 00:27:43.400
<v Speaker 1>Okay, identify the enemy then bypass it. He gives lots

546
00:27:43.440 --> 00:27:45.480
<v Speaker 1>of exss bypass examples a ton.

547
00:27:45.799 --> 00:27:50.000
<v Speaker 2>It shows how complex evasion can be. Things like changing

548
00:27:50.079 --> 00:27:54.119
<v Speaker 2>character case script instead of script, injecting white space or

549
00:27:54.119 --> 00:27:58.559
<v Speaker 2>comments using alternative tags like SVG or iframe, src doc,

550
00:27:59.079 --> 00:28:03.119
<v Speaker 2>different event hands form action on input on drag using

551
00:28:03.200 --> 00:28:07.920
<v Speaker 2>data urs wow using lesser known event handlers, manipulating the

552
00:28:07.960 --> 00:28:13.359
<v Speaker 2>location object in JavaScript, unicode separators, various encoding or obfustation tricks,

553
00:28:13.759 --> 00:28:16.799
<v Speaker 2>using alternative execution sinks like set time out or set

554
00:28:16.799 --> 00:28:19.839
<v Speaker 2>interval or the function constructor instead of direct script tags.

555
00:28:19.839 --> 00:28:20.680
<v Speaker 2>It's an arms race.

556
00:28:20.759 --> 00:28:23.839
<v Speaker 1>Definitely sounds like it. Finally, after finding all these vulnerabilities,

557
00:28:23.920 --> 00:28:24.880
<v Speaker 1>you have to report them right.

558
00:28:25.000 --> 00:28:28.200
<v Speaker 2>Report writing absolutely crucial. A finding is useless if you

559
00:28:28.200 --> 00:28:31.839
<v Speaker 2>can't communicate it effectively. Block stress is understanding your audience.

560
00:28:32.119 --> 00:28:34.400
<v Speaker 2>Are you writing for technical staff who need details or

561
00:28:34.440 --> 00:28:36.240
<v Speaker 2>executives who need the business impact?

562
00:28:36.559 --> 00:28:38.720
<v Speaker 1>So tailor the report. What are the key parts?

563
00:28:38.920 --> 00:28:42.480
<v Speaker 2>An executive summary, high level business language, a finding summary,

564
00:28:43.200 --> 00:28:46.400
<v Speaker 2>maybe a historical comparison if it's a repeat test. The

565
00:28:46.440 --> 00:28:52.000
<v Speaker 2>methodology used a narrative of the testing risk assessment CBSS scores,

566
00:28:52.000 --> 00:28:55.839
<v Speaker 2>but also considering business context, maybe a risk matrix.

567
00:28:55.400 --> 00:28:57.000
<v Speaker 1>And the technical details, yes.

568
00:28:56.880 --> 00:29:00.839
<v Speaker 2>The detailed technical report. Each finding needs clear, evident steps

569
00:29:00.880 --> 00:29:03.759
<v Speaker 2>to reproduce it and recommendations for fixing it. He also

570
00:29:03.799 --> 00:29:06.759
<v Speaker 2>mentions organizing the report logically and tools that can help

571
00:29:07.000 --> 00:29:10.359
<v Speaker 2>like Dratus, attack Forge or even using AI like chat

572
00:29:10.400 --> 00:29:12.119
<v Speaker 2>GPT to assist with drafting.

573
00:29:12.240 --> 00:29:16.319
<v Speaker 1>Any final tips on writing good reports clearly convey the impact.

574
00:29:16.480 --> 00:29:19.519
<v Speaker 2>Why should the business care about this vulnerability? Use real

575
00:29:19.559 --> 00:29:22.039
<v Speaker 2>world examples if possible, make it easy for them to

576
00:29:22.119 --> 00:29:24.039
<v Speaker 2>understand the risk and prioritize fixes.

577
00:29:24.119 --> 00:29:27.160
<v Speaker 1>Okay, that was a lot a comprehensive tour.

578
00:29:27.279 --> 00:29:29.839
<v Speaker 2>It really covers the breadth of modern web haacking. We've

579
00:29:29.839 --> 00:29:33.359
<v Speaker 2>gone from the basics of HTP through detailed recon server

580
00:29:33.519 --> 00:29:37.480
<v Speaker 2>side flaws like SEQY and SSTI, client side like EXSS and.

581
00:29:37.519 --> 00:29:42.319
<v Speaker 1>CSRF filesystem attacks, off issues, business logic flaws xx E,

582
00:29:42.599 --> 00:29:47.319
<v Speaker 1>SSRF de serialization, attacking APIs and serverlests.

583
00:29:46.920 --> 00:29:52.480
<v Speaker 2>HTML five issues, WAF bypasses, and finally reporting. It really

584
00:29:52.519 --> 00:29:54.279
<v Speaker 2>shows the multiple layers.

585
00:29:53.920 --> 00:29:56.400
<v Speaker 1>Involved and this is all drawn from that real world

586
00:29:56.400 --> 00:30:01.440
<v Speaker 1>perspective in rafe blotch web haacking arsenal. It's a look

587
00:30:01.480 --> 00:30:03.000
<v Speaker 1>at how the pros actually do it.

588
00:30:03.119 --> 00:30:07.319
<v Speaker 2>Absolutely, it highlights the practical techniques used to find weaknesses

589
00:30:07.319 --> 00:30:09.279
<v Speaker 2>and the applications we all rely on.

590
00:30:09.319 --> 00:30:11.720
<v Speaker 1>Which leads to maybe a final thought for you listening.

591
00:30:12.119 --> 00:30:16.240
<v Speaker 1>Given everything we've just discussed all these different types of vulnerabilities.

592
00:30:15.519 --> 00:30:19.039
<v Speaker 2>It's worth thinking about how these often invisible weaknesses might

593
00:30:19.039 --> 00:30:21.759
<v Speaker 2>be impacting the security and privacy of the websites and

594
00:30:21.799 --> 00:30:23.480
<v Speaker 2>apps you use every single day.

595
00:30:23.640 --> 00:30:27.519
<v Speaker 1>Yeah, security is this constant background process, this layer we

596
00:30:27.559 --> 00:30:31.039
<v Speaker 1>don't usually see, but it has potential failure points everywhere.

597
00:30:31.079 --> 00:30:34.000
<v Speaker 2>It really demands constant vigilance from developers and testers.

598
00:30:34.200 --> 00:30:36.599
<v Speaker 1>We definitely encourage you to explore these topics more if

599
00:30:36.640 --> 00:30:39.279
<v Speaker 1>you're interested, maybe even check out Block's book for the

600
00:30:39.400 --> 00:30:42.799
<v Speaker 1>full deep details. Web security is always.

601
00:30:42.440 --> 00:30:45.039
<v Speaker 2>Evolving, Continuous learning is essential in this field.

602
00:30:45.200 --> 00:30:47.079
<v Speaker 1>Well, thanks for taking this deep dive with US today