WEBVTT

1
00:00:00.040 --> 00:00:02.080
<v Speaker 1>What if you could get paid to break things, I

2
00:00:02.120 --> 00:00:07.080
<v Speaker 1>mean legally and ethically find hidden weaknesses in the digital

3
00:00:07.200 --> 00:00:09.439
<v Speaker 1>armor of some really big tech companies.

4
00:00:09.519 --> 00:00:11.960
<v Speaker 2>Yeah, it sounds a bit counterintuitive, doesn't it. Yeah, but

5
00:00:12.000 --> 00:00:12.720
<v Speaker 2>it's a real thing.

6
00:00:12.919 --> 00:00:16.719
<v Speaker 1>We're diving into, well, a pretty fascinating field today where

7
00:00:16.760 --> 00:00:19.879
<v Speaker 1>curiosity meets critical thinking and you know, the payout can

8
00:00:19.920 --> 00:00:21.199
<v Speaker 1>actually be quite impressive.

9
00:00:21.359 --> 00:00:23.960
<v Speaker 2>It's true. We're talking about the world of web security

10
00:00:24.079 --> 00:00:29.120
<v Speaker 2>and bug bounty hunting. It's a really crucial front line

11
00:00:29.359 --> 00:00:32.200
<v Speaker 2>in protecting well, pretty much everything we do online now.

12
00:00:32.280 --> 00:00:35.119
<v Speaker 1>Absolutely, so today we're doing a deep dive into bug

13
00:00:35.159 --> 00:00:38.600
<v Speaker 1>bounty hunting for web security. Our mission really is to

14
00:00:38.640 --> 00:00:43.079
<v Speaker 1>cut through the jargon, understand the core ideas, the clever

15
00:00:43.159 --> 00:00:46.679
<v Speaker 1>techniques and the essential tools that let security pros find

16
00:00:46.679 --> 00:00:48.920
<v Speaker 1>these vulnerabilities in web apps, right.

17
00:00:48.759 --> 00:00:51.960
<v Speaker 2>And how they help prevent malicious attacks and yeah, sometimes

18
00:00:52.039 --> 00:00:53.920
<v Speaker 2>even or in a nice bounty for doing it.

19
00:00:54.039 --> 00:00:57.200
<v Speaker 1>And this deep dive it pulls insights from a pretty

20
00:00:57.200 --> 00:01:00.439
<v Speaker 1>comprehensive guide, right, an experts view on the let's say,

21
00:01:00.840 --> 00:01:03.240
<v Speaker 1>offensive side of bug hunting exactly.

22
00:01:03.280 --> 00:01:06.879
<v Speaker 2>We're going to unpack how ethical hackers think, what specific

23
00:01:06.879 --> 00:01:11.239
<v Speaker 2>weaknesses they target, and the frankly powerful tools they use

24
00:01:11.239 --> 00:01:13.560
<v Speaker 2>in this constant sort of digital chess match.

25
00:01:13.760 --> 00:01:16.400
<v Speaker 1>Okay, let's get into it then. So the big question first,

26
00:01:16.680 --> 00:01:20.400
<v Speaker 1>why why would someone actually dedicate their time to hunting

27
00:01:20.439 --> 00:01:22.640
<v Speaker 1>for bugs? What's the real pull?

28
00:01:23.079 --> 00:01:26.480
<v Speaker 2>Well, there are a few pretty strong motivations actually. First,

29
00:01:26.599 --> 00:01:29.239
<v Speaker 2>it just makes you a better security professional, plain and simple.

30
00:01:29.480 --> 00:01:32.319
<v Speaker 2>If you understand how attackers operate, you get way better

31
00:01:32.359 --> 00:01:32.879
<v Speaker 2>at defending.

32
00:01:33.000 --> 00:01:35.000
<v Speaker 1>That makes sense, know your enemy kind.

33
00:01:34.799 --> 00:01:39.760
<v Speaker 2>Of thing precisely. Second, there's well a huge element of recognition,

34
00:01:40.000 --> 00:01:43.599
<v Speaker 2>you know, respect within the cybersecurity community. Finding a critical

35
00:01:43.640 --> 00:01:46.840
<v Speaker 2>bug in a major platform that really builds your credibility fast.

36
00:01:47.000 --> 00:01:49.120
<v Speaker 1>And the money you mentioned bounties.

37
00:01:48.879 --> 00:01:52.239
<v Speaker 2>Oh yeah, and of course the financial side can be significant.

38
00:01:52.280 --> 00:01:56.439
<v Speaker 2>It's definitely not uncommon for top hunters to earn substantial

39
00:01:56.480 --> 00:01:59.640
<v Speaker 2>sums for finding really high impact vulnerabilities.

40
00:02:00.239 --> 00:02:03.920
<v Speaker 1>That's a key point. It's not some niche hobby anymore.

41
00:02:04.400 --> 00:02:09.280
<v Speaker 1>Big names like Google, Facebook, Twitter, they aren't just putting

42
00:02:09.360 --> 00:02:12.319
<v Speaker 1>up with this, They're actively encouraging it with their own

43
00:02:12.599 --> 00:02:13.840
<v Speaker 1>bug bounty programs.

44
00:02:14.039 --> 00:02:16.759
<v Speaker 2>Right, It's become a standard practice. It's a win win really.

45
00:02:17.159 --> 00:02:21.120
<v Speaker 2>They get their security strengthened and skilled people get rewarded

46
00:02:21.400 --> 00:02:22.439
<v Speaker 2>for finding the flaws.

47
00:02:22.599 --> 00:02:25.639
<v Speaker 1>What's really interesting, though, is the ethical angle. The guide

48
00:02:26.159 --> 00:02:27.319
<v Speaker 1>is clear on this, isn't it?

49
00:02:27.360 --> 00:02:31.759
<v Speaker 2>Oh, absolutely crystal clear. You're learning these attacking techniques quote

50
00:02:31.840 --> 00:02:35.840
<v Speaker 2>unquote specifically for defense. You're essentially becoming a white hat

51
00:02:35.840 --> 00:02:39.120
<v Speaker 2>hacker or maybe a penetration tester to find those flaws

52
00:02:39.240 --> 00:02:41.759
<v Speaker 2>before the h the actual bad guys do.

53
00:02:41.960 --> 00:02:44.360
<v Speaker 1>So the knowledge is like a shield, not a weapon,

54
00:02:44.479 --> 00:02:45.759
<v Speaker 1>for causing trouble.

55
00:02:45.560 --> 00:02:47.759
<v Speaker 2>Exactly, never from malpractice.

56
00:02:47.159 --> 00:02:49.759
<v Speaker 1>Which naturally brings up the legal side. There's a very

57
00:02:49.759 --> 00:02:51.599
<v Speaker 1>bright line here. You just cannot cross.

58
00:02:51.680 --> 00:02:55.000
<v Speaker 2>Cannot stress this enough. You must never ever attack systems

59
00:02:55.080 --> 00:02:58.759
<v Speaker 2>without the owner's explicit permission. Seriously, this is an.

60
00:02:58.680 --> 00:03:02.000
<v Speaker 1>Optional and the consequence if you do they can be severe.

61
00:03:02.159 --> 00:03:04.520
<v Speaker 2>It's against the law in many places, and it could

62
00:03:04.560 --> 00:03:08.599
<v Speaker 2>easily end a potential career before he even gets off the ground.

63
00:03:08.639 --> 00:03:09.280
<v Speaker 2>Just don't do it.

64
00:03:09.319 --> 00:03:12.680
<v Speaker 1>Okay. So for someone starting out thinking this sounds interesting,

65
00:03:13.240 --> 00:03:16.000
<v Speaker 1>how do they get that permission? How do they stay legal?

66
00:03:16.719 --> 00:03:21.400
<v Speaker 2>The advice is pretty straightforward. Register with established bug bounty platforms,

67
00:03:21.879 --> 00:03:25.639
<v Speaker 2>you know places like bug crowd Hacker, one, Cobalt, there's

68
00:03:25.680 --> 00:03:28.719
<v Speaker 2>even the Japan bug bounty program Anti hack.

69
00:03:28.919 --> 00:03:31.240
<v Speaker 1>These platforms provide the framework.

70
00:03:31.319 --> 00:03:34.479
<v Speaker 2>Yeah, they act as the intermediary, They provide the legal sandbox.

71
00:03:34.560 --> 00:03:37.080
<v Speaker 2>The rules of engagement are clear, so you know you're

72
00:03:37.080 --> 00:03:38.879
<v Speaker 2>operating within legitimate boundaries.

73
00:03:38.919 --> 00:03:43.159
<v Speaker 1>Got it. But finding these exploits, it's not like just

74
00:03:43.240 --> 00:03:45.800
<v Speaker 1>running a quick scan is it sounds like it takes

75
00:03:45.960 --> 00:03:47.080
<v Speaker 1>some serious effort.

76
00:03:47.120 --> 00:03:49.919
<v Speaker 2>Oh. Absolutely, there's a steep learning curve involved, no doubt.

77
00:03:49.960 --> 00:03:53.199
<v Speaker 2>You need a pretty deep understanding of how web applications

78
00:03:53.240 --> 00:03:57.000
<v Speaker 2>are built, the HGTP protocol itself, different encoding schemes, all

79
00:03:57.039 --> 00:03:58.479
<v Speaker 2>the different types of attacks out there.

80
00:03:58.479 --> 00:04:01.360
<v Speaker 1>So it's less about just knowing the it's much.

81
00:04:01.159 --> 00:04:04.879
<v Speaker 2>More about understanding the underlying logic. You know how the

82
00:04:04.919 --> 00:04:08.159
<v Speaker 2>web actually works and where those fundamental building blocks can

83
00:04:08.199 --> 00:04:10.039
<v Speaker 2>be well twisted or subverted.

84
00:04:10.280 --> 00:04:12.840
<v Speaker 1>Okay, so if you had to boil it down, what

85
00:04:13.039 --> 00:04:15.360
<v Speaker 1>is a bug bounty hunter? A simple definition?

86
00:04:15.479 --> 00:04:18.519
<v Speaker 2>Sure, At its core, a bug bounty hunter is an

87
00:04:18.560 --> 00:04:22.279
<v Speaker 2>ethical hacker who gets paid to find vulnerabilities in software

88
00:04:22.279 --> 00:04:26.279
<v Speaker 2>and websites. Simple as that, really, but pretty powerful.

89
00:04:26.399 --> 00:04:29.800
<v Speaker 1>That's a great summary. Now, Okay, someone's intrigued, they're thinking

90
00:04:29.800 --> 00:04:33.040
<v Speaker 1>about trying this, But you can't just start poking around

91
00:04:33.079 --> 00:04:36.519
<v Speaker 1>on say Google's live servers. Right, you need a safe space.

92
00:04:37.120 --> 00:04:40.360
<v Speaker 1>Why is setting up a virtual lab so vital for beginners?

93
00:04:40.639 --> 00:04:44.680
<v Speaker 2>It's absolutely crucial paramount even because it lets you practice

94
00:04:44.759 --> 00:04:48.439
<v Speaker 2>using all these hacking tools legally and more importantly, safely

95
00:04:48.879 --> 00:04:50.199
<v Speaker 2>on your own system.

96
00:04:49.959 --> 00:04:52.199
<v Speaker 1>Like a digital sandbox exactly like that.

97
00:04:52.319 --> 00:04:55.639
<v Speaker 2>Think of it as a controlled test chamber. If some

98
00:04:55.720 --> 00:04:58.079
<v Speaker 2>malicious code gets loose, or maybe a tool doesn't behave

99
00:04:58.120 --> 00:05:01.439
<v Speaker 2>as expected, it's all contained with in that simulated environment.

100
00:05:01.480 --> 00:05:03.000
<v Speaker 2>It won't trash your main computer.

101
00:05:03.240 --> 00:05:05.759
<v Speaker 1>Ah okay, so it protects your actual machine.

102
00:05:05.959 --> 00:05:09.879
<v Speaker 2>Right, it's your personal risk free playground. You can just experiment,

103
00:05:09.959 --> 00:05:12.720
<v Speaker 2>try everything that comes into your head without worrying about

104
00:05:12.759 --> 00:05:16.639
<v Speaker 2>breaking anything important or accidentally attacking someone else.

105
00:05:16.920 --> 00:05:19.399
<v Speaker 1>Makes perfect sense, like a crash test dummy for your

106
00:05:19.439 --> 00:05:23.680
<v Speaker 1>digital experiments. So what tools and setups do you recommend

107
00:05:23.759 --> 00:05:25.560
<v Speaker 1>for building this virtual lab?

108
00:05:26.120 --> 00:05:30.000
<v Speaker 2>For beginners? Virtual Box is usually the top recommendation. It's

109
00:05:30.040 --> 00:05:33.079
<v Speaker 2>super versatile because it runs on pretty much any operating

110
00:05:33.079 --> 00:05:36.040
<v Speaker 2>system Windows, Linux, Mac OS, so.

111
00:05:36.000 --> 00:05:37.040
<v Speaker 1>It works wherever you are.

112
00:05:37.199 --> 00:05:40.199
<v Speaker 2>Yeah, it's compatibility and relative ease of use make it

113
00:05:40.240 --> 00:05:42.839
<v Speaker 2>a really good starting point for setting up a security lab.

114
00:05:43.120 --> 00:05:45.759
<v Speaker 1>And once you have virtual Box running, what os should

115
00:05:45.759 --> 00:05:48.240
<v Speaker 1>you install inside it for this kind of work.

116
00:05:48.480 --> 00:05:50.879
<v Speaker 2>Colie Linux is definitely the go to choice for most

117
00:05:50.920 --> 00:05:52.399
<v Speaker 2>people starting in ethical hacking.

118
00:05:52.600 --> 00:05:55.240
<v Speaker 1>Why Collie specifically because.

119
00:05:54.839 --> 00:05:58.120
<v Speaker 2>It comes preloaded with just a massive suite of essential

120
00:05:58.160 --> 00:06:01.319
<v Speaker 2>security tools, hundreds of them. It just streamlines the setup

121
00:06:01.360 --> 00:06:04.399
<v Speaker 2>process incredibly. You basically get a hacker's toolkit ready to

122
00:06:04.399 --> 00:06:06.079
<v Speaker 2>go right out of the virtual box.

123
00:06:06.240 --> 00:06:09.920
<v Speaker 1>Okay, that's convenient. So we've got Collie running inside virtual box.

124
00:06:10.639 --> 00:06:14.079
<v Speaker 1>What are the first few core tools someone would likely

125
00:06:14.120 --> 00:06:16.720
<v Speaker 1>start using to actually hunt for vulnerabilities.

126
00:06:17.240 --> 00:06:20.439
<v Speaker 2>Well, you'll quickly become familiar with tools like burp suite

127
00:06:21.000 --> 00:06:25.480
<v Speaker 2>and wasp bz ABP. These are what we call interception proxies.

128
00:06:25.600 --> 00:06:27.439
<v Speaker 1>Interception proxies. How do they work?

129
00:06:27.720 --> 00:06:32.959
<v Speaker 2>Imagine like a control tower for your web traffic. Every

130
00:06:33.040 --> 00:06:36.240
<v Speaker 2>single piece of information your browser sends to a website

131
00:06:36.600 --> 00:06:39.199
<v Speaker 2>or receives back passes through this tool.

132
00:06:38.959 --> 00:06:41.279
<v Speaker 1>First, so you can see everything exactly.

133
00:06:41.560 --> 00:06:44.279
<v Speaker 2>They capture all the traffic from the web application you're targeting,

134
00:06:44.680 --> 00:06:48.480
<v Speaker 2>just less you inspect it, analyze it, even modify requests

135
00:06:48.519 --> 00:06:51.040
<v Speaker 2>before they hit the server or responses before they reach

136
00:06:51.079 --> 00:06:52.000
<v Speaker 2>your browser.

137
00:06:51.680 --> 00:06:53.920
<v Speaker 1>Like being a man in the middle, but for ethical reasons.

138
00:06:53.959 --> 00:06:57.399
<v Speaker 2>Precisely give you incredible control and visibility. But it's also

139
00:06:57.439 --> 00:07:00.240
<v Speaker 2>really important to remember relying on just one tool that's

140
00:07:00.279 --> 00:07:02.360
<v Speaker 2>usually a bad idea in this field. Why is that

141
00:07:02.720 --> 00:07:07.720
<v Speaker 2>because no single tool catches everything. Different tools have different strengths,

142
00:07:07.920 --> 00:07:11.120
<v Speaker 2>different ways of looking at things, So having a diverse

143
00:07:11.160 --> 00:07:15.959
<v Speaker 2>toolkit is always always better for doing comprehensive testing. You'll

144
00:07:15.959 --> 00:07:17.240
<v Speaker 2>miss things otherwise, right.

145
00:07:17.160 --> 00:07:19.600
<v Speaker 1>So it's not about one magic bullet tool, but building

146
00:07:19.600 --> 00:07:22.360
<v Speaker 1>an arsenal. And where do you practice with these tools

147
00:07:22.360 --> 00:07:24.279
<v Speaker 1>if you can't just point them at live websites?

148
00:07:24.399 --> 00:07:27.720
<v Speaker 2>Ah, that's where applications like webgoat come in. It's deliberately

149
00:07:27.800 --> 00:07:30.720
<v Speaker 2>designed to be insecure, built to be broken pretty much.

150
00:07:31.000 --> 00:07:34.600
<v Speaker 2>It's made by OAS, the Open Web Application Security Project,

151
00:07:35.040 --> 00:07:38.680
<v Speaker 2>specifically for learning and testing common web app vulnerabilities. You

152
00:07:38.759 --> 00:07:41.079
<v Speaker 2>run it locally, usually on your own machine, at an

153
00:07:41.079 --> 00:07:44.560
<v Speaker 2>address like http dot localhost dot a zero a zero web.

154
00:07:44.360 --> 00:07:47.120
<v Speaker 1>Gooat, and because it's local and designed for testing, you.

155
00:07:47.040 --> 00:07:49.399
<v Speaker 2>Can experiment as much as you want, try all sorts

156
00:07:49.439 --> 00:07:52.399
<v Speaker 2>of attacks without any legal risk whatsoever. It's the perfect

157
00:07:52.399 --> 00:07:53.040
<v Speaker 2>training ground.

158
00:07:53.439 --> 00:07:57.800
<v Speaker 1>Are there other Linux distributions besides Collie that ethical hackers

159
00:07:57.839 --> 00:07:59.839
<v Speaker 1>sometimes use? Maybe for more specialized.

160
00:08:00.600 --> 00:08:03.279
<v Speaker 2>Oh sure, Kalli is the most popular, but there are others.

161
00:08:03.639 --> 00:08:07.040
<v Speaker 2>Black Arts, linuxes well a behemoth. It boasts something like

162
00:08:07.079 --> 00:08:09.360
<v Speaker 2>over nineteen hundred tools pre installed.

163
00:08:09.480 --> 00:08:09.839
<v Speaker 1>Wow.

164
00:08:10.000 --> 00:08:13.759
<v Speaker 2>Yeah. Then for users who want extreme security through isolation,

165
00:08:13.959 --> 00:08:19.360
<v Speaker 2>there's quebsos. It compartmentalizes everything into separate, isolated virtual machines. Interesting,

166
00:08:19.480 --> 00:08:21.480
<v Speaker 2>and you also have things like in pre doos which

167
00:08:21.560 --> 00:08:25.040
<v Speaker 2>uses the anonymous IP network and hunix, which leverages the

168
00:08:25.079 --> 00:08:28.279
<v Speaker 2>tour network for you know, enhance privacy and anonymity. Each

169
00:08:28.279 --> 00:08:29.079
<v Speaker 2>has its niche.

170
00:08:29.240 --> 00:08:32.679
<v Speaker 1>Okay, so we've covered the why and the how to

171
00:08:32.759 --> 00:08:35.639
<v Speaker 1>set up our ethical hacking playground. Now for the really

172
00:08:35.720 --> 00:08:40.240
<v Speaker 1>juicy stuff, let's dive into some specific web vulnerabilities. Often

173
00:08:40.320 --> 00:08:43.000
<v Speaker 1>ethical hackers start by looking for subtle tricks, right like

174
00:08:43.279 --> 00:08:45.639
<v Speaker 1>cross site requests forgery or CSRF.

175
00:08:45.679 --> 00:08:48.399
<v Speaker 2>What exactly is that CSRF? Yeah, often pronounced sea surf.

176
00:08:48.960 --> 00:08:51.200
<v Speaker 2>It's an attack where a malicious request gets sent from

177
00:08:51.200 --> 00:08:53.840
<v Speaker 2>a user's browser without them even knowing it or intending it.

178
00:08:53.960 --> 00:08:56.159
<v Speaker 1>How does that work? How can my browser send something

179
00:08:56.159 --> 00:08:57.000
<v Speaker 1>I didn't ask it to?

180
00:08:57.320 --> 00:09:01.159
<v Speaker 2>Think of it like this? Your already logged into your bank,

181
00:09:01.840 --> 00:09:05.879
<v Speaker 2>right your browser has a valid session cookie. The attacker

182
00:09:05.919 --> 00:09:08.960
<v Speaker 2>tricks your browser into submitting another request to your bank,

183
00:09:09.080 --> 00:09:12.519
<v Speaker 2>say to transfer money, leveraging that existing logged in session.

184
00:09:13.039 --> 00:09:16.000
<v Speaker 2>Your browser just does what it's told, thinking the request

185
00:09:16.039 --> 00:09:17.559
<v Speaker 2>is legitimate because.

186
00:09:17.519 --> 00:09:20.320
<v Speaker 1>While you're logged in, so the users logged in, everything

187
00:09:20.360 --> 00:09:24.519
<v Speaker 1>seems normal. How does the attacker actually trigger that unwanted request?

188
00:09:24.679 --> 00:09:27.360
<v Speaker 2>They can create a seemingly harmless web page, maybe with

189
00:09:27.440 --> 00:09:29.759
<v Speaker 2>just an image or a link on it. Hidden on

190
00:09:29.799 --> 00:09:32.759
<v Speaker 2>that page is an HTML form. When your browser lows

191
00:09:32.799 --> 00:09:35.600
<v Speaker 2>that page, maybe even just the hidden image pixel, some

192
00:09:35.720 --> 00:09:39.200
<v Speaker 2>JavaScript in the background like document dot form zero dot submit,

193
00:09:39.720 --> 00:09:41.399
<v Speaker 2>automatically submits that hit en form.

194
00:09:41.519 --> 00:09:44.360
<v Speaker 1>And because my browser is already logged into the vulnerable.

195
00:09:43.919 --> 00:09:47.519
<v Speaker 2>Site exactly, that malicious request often just sails right through

196
00:09:47.559 --> 00:09:50.879
<v Speaker 2>the defenses because it includes your valid session cookies, the

197
00:09:50.919 --> 00:09:51.919
<v Speaker 2>server thinks you sent it.

198
00:09:52.080 --> 00:09:55.240
<v Speaker 1>Wow, So it's less about injecting bad code and more

199
00:09:55.240 --> 00:09:58.039
<v Speaker 1>about tricking the browser into being an unwitting accomplice.

200
00:09:58.440 --> 00:10:00.799
<v Speaker 2>That's a great way to put it. Bloids the trust

201
00:10:00.879 --> 00:10:03.679
<v Speaker 2>between a user's browser and the site they're logged into.

202
00:10:04.000 --> 00:10:07.399
<v Speaker 1>So how do developers stop this? What's the key defense

203
00:10:07.440 --> 00:10:08.360
<v Speaker 1>against CSRF?

204
00:10:08.759 --> 00:10:12.360
<v Speaker 2>The core defense is using CSRF tokens for every action

205
00:10:12.440 --> 00:10:15.440
<v Speaker 2>the user takes that changes something like changing a password

206
00:10:15.519 --> 00:10:19.679
<v Speaker 2>or sending money, the server should require a secret, unique,

207
00:10:19.960 --> 00:10:23.440
<v Speaker 2>unpredictable token to be submitted along with the request, and

208
00:10:23.480 --> 00:10:26.799
<v Speaker 2>this token proves it proves that the request really originated

209
00:10:26.799 --> 00:10:30.159
<v Speaker 2>from the legitimate user interface on the site itself and

210
00:10:30.240 --> 00:10:33.240
<v Speaker 2>not from some malicious third party page. Yeah, credit for

211
00:10:33.399 --> 00:10:36.120
<v Speaker 2>is a request. If the token is missing or invalid,

212
00:10:36.320 --> 00:10:37.840
<v Speaker 2>the server just rejects the action.

213
00:10:38.200 --> 00:10:42.679
<v Speaker 1>Fascinating. Okay, Next up, cross site scripting XSS. This one

214
00:10:42.679 --> 00:10:44.840
<v Speaker 1>feels like it's been around forever, but it's still a

215
00:10:45.000 --> 00:10:45.919
<v Speaker 1>huge problem, right.

216
00:10:45.919 --> 00:10:50.080
<v Speaker 2>Oh, absolutely, EXSS is still incredibly common. It involves injecting

217
00:10:50.120 --> 00:10:53.639
<v Speaker 2>malicious browser site scripts, usually it's JavaScript, into a web application.

218
00:10:53.799 --> 00:10:55.080
<v Speaker 1>How does that injection happen?

219
00:10:55.399 --> 00:10:59.639
<v Speaker 2>Typically it's because user input fields aren't properly sanitized or validated.

220
00:11:00.320 --> 00:11:02.320
<v Speaker 2>Think about a comment section on a blog or a

221
00:11:02.360 --> 00:11:06.960
<v Speaker 2>search bar. If I can type something like scriptrol create

222
00:11:07.120 --> 00:11:09.600
<v Speaker 2>been hacked script into that field and.

223
00:11:09.559 --> 00:11:12.879
<v Speaker 1>The website just displays it as raw HTML.

224
00:11:12.480 --> 00:11:17.039
<v Speaker 2>Exactly, then every single user who views that page or

225
00:11:17.080 --> 00:11:20.679
<v Speaker 2>maybe sees that search result will have my malicious script

226
00:11:20.799 --> 00:11:24.399
<v Speaker 2>run in their browser within the context of the trusted website.

227
00:11:24.679 --> 00:11:27.440
<v Speaker 1>So attackers are basically probing every place a user can

228
00:11:27.440 --> 00:11:30.519
<v Speaker 1>type something in looking for a spot where raw HTML

229
00:11:30.600 --> 00:11:32.159
<v Speaker 1>or jobscript might slip through.

230
00:11:32.000 --> 00:11:34.679
<v Speaker 2>The cracks precisely. And the reason it's so hard to

231
00:11:34.679 --> 00:11:38.759
<v Speaker 2>prevent entirely, especially on huge complex applications like say Google

232
00:11:38.840 --> 00:11:42.080
<v Speaker 2>or Facebook, is just the sheer scale. You have thousands

233
00:11:42.120 --> 00:11:45.639
<v Speaker 2>of developers, millions of lines of code ensuring every single

234
00:11:45.639 --> 00:11:49.120
<v Speaker 2>input fuel everywhere perfectly strips out every potentially harmful tag

235
00:11:49.200 --> 00:11:51.080
<v Speaker 2>or script. It's a monumental challenge.

236
00:11:51.159 --> 00:11:54.120
<v Speaker 1>Just one little oversight can open a huge door.

237
00:11:53.879 --> 00:11:56.720
<v Speaker 2>A massive door. That's why EXSS remains one of the

238
00:11:56.759 --> 00:11:59.120
<v Speaker 2>most prevalent vulnerabilities found by bug hunters.

239
00:11:59.279 --> 00:12:02.360
<v Speaker 1>So the core insight here isn't just about the script itself,

240
00:12:02.440 --> 00:12:06.000
<v Speaker 1>is it. It's about how absolutely critical every single point

241
00:12:06.039 --> 00:12:10.919
<v Speaker 1>of user input becomes. A tiny mistake can compromise potentially

242
00:12:11.039 --> 00:12:12.320
<v Speaker 1>everyone using the site.

243
00:12:12.360 --> 00:12:14.759
<v Speaker 2>That's exactly it. The impact can be widespread.

244
00:12:14.960 --> 00:12:17.919
<v Speaker 1>How would a hacker approach finding EXSS in a safe

245
00:12:18.000 --> 00:12:21.120
<v Speaker 1>test environment like one of those deliberately vulnerable.

246
00:12:20.600 --> 00:12:25.000
<v Speaker 2>Apps, Well, using something like o WASP, Broken Web Application

247
00:12:25.399 --> 00:12:29.759
<v Speaker 2>or BWPP. You'd start by systematically trying to inject simple

248
00:12:29.879 --> 00:12:33.120
<v Speaker 2>jobscript snippets into various input fields. You know, like that

249
00:12:33.279 --> 00:12:36.120
<v Speaker 2>basic alert Hello, this is reflected XSS.

250
00:12:36.399 --> 00:12:38.320
<v Speaker 1>Payload, just to see if anything executes.

251
00:12:38.399 --> 00:12:40.120
<v Speaker 2>Yeah, just to see if you get that pop up box.

252
00:12:40.519 --> 00:12:43.679
<v Speaker 2>And tools like burp suite and o wasp ZAPPI are

253
00:12:43.759 --> 00:12:47.639
<v Speaker 2>indispensable here. Zapip, for instance, is really helpful because it

254
00:12:47.639 --> 00:12:51.240
<v Speaker 2>doesn't just flag potential vulnerabilities with those colored alerts red

255
00:12:51.240 --> 00:12:53.879
<v Speaker 2>for high risk, orange for medium, yellow for low.

256
00:12:54.000 --> 00:12:54.919
<v Speaker 1>It tells you how to fix it.

257
00:12:54.960 --> 00:12:58.519
<v Speaker 2>Too often, yes, it'll suggest concrete solutions, like maybe adding

258
00:12:58.519 --> 00:13:01.759
<v Speaker 2>the x frame options ny header to prevent certain types

259
00:13:01.759 --> 00:13:03.720
<v Speaker 2>of attacks like clickjacking, which is related.

260
00:13:03.960 --> 00:13:05.960
<v Speaker 1>So z adp gives you a bit of a roadmap

261
00:13:05.960 --> 00:13:07.879
<v Speaker 1>for both finding and fixing the issue.

262
00:13:08.080 --> 00:13:12.200
<v Speaker 2>It definitely can and for more systematic testing, maybe trying

263
00:13:12.240 --> 00:13:16.080
<v Speaker 2>lots of different EXSS variations. Burp Suite's intruder tool is

264
00:13:16.120 --> 00:13:18.679
<v Speaker 2>incredibly powerful. You can feed it a whole list of

265
00:13:18.759 --> 00:13:22.279
<v Speaker 2>known EXSS payloads and just automate the process of sending

266
00:13:22.320 --> 00:13:25.320
<v Speaker 2>them to various input fields looking for responses that indicate

267
00:13:25.360 --> 00:13:27.279
<v Speaker 2>your script actually executed successfully.

268
00:13:27.360 --> 00:13:30.679
<v Speaker 1>Okay, let's switch gears to header injection and URL redirection.

269
00:13:31.440 --> 00:13:34.600
<v Speaker 1>What's the basic weakness here what allows this kind of attack?

270
00:13:34.960 --> 00:13:38.600
<v Speaker 2>This vulnerability pops up when an application takes user input,

271
00:13:38.759 --> 00:13:41.519
<v Speaker 2>maybe from a URL parameter, and uses it directly to

272
00:13:41.639 --> 00:13:45.279
<v Speaker 2>decide where to redirect the user's browser without properly checking

273
00:13:45.360 --> 00:13:46.799
<v Speaker 2>or validating that input first.

274
00:13:46.960 --> 00:13:49.480
<v Speaker 1>So instead of sending you to a safe fixed.

275
00:13:49.120 --> 00:13:53.080
<v Speaker 2>Location right, instead of having SAFECode like header location dot https,

276
00:13:53.120 --> 00:13:56.799
<v Speaker 2>do wwwang dot site hard coded, the vulnerable code might

277
00:13:56.799 --> 00:13:59.679
<v Speaker 2>look more like response dot send, redirect, request dot get parameter,

278
00:13:59.799 --> 00:14:03.759
<v Speaker 2>or just blindly trust whatever URL the user or attacker

279
00:14:03.840 --> 00:14:05.360
<v Speaker 2>provides in that parameter, and.

280
00:14:05.240 --> 00:14:07.799
<v Speaker 1>That opens the door to what's the main risk for

281
00:14:07.879 --> 00:14:08.320
<v Speaker 1>the user.

282
00:14:08.679 --> 00:14:12.879
<v Speaker 2>The biggest risk is usually very convincing phishing attacks. An

283
00:14:12.919 --> 00:14:15.720
<v Speaker 2>attacker can craft a special URL that looks like it

284
00:14:15.759 --> 00:14:18.720
<v Speaker 2>belongs to the legitimate website, but when you click it,

285
00:14:19.039 --> 00:14:22.919
<v Speaker 2>that vulnerable redirect parameter sends your browser seamlessly to a

286
00:14:22.960 --> 00:14:26.639
<v Speaker 2>malicious site designed to steal your credentials or drop malware.

287
00:14:27.080 --> 00:14:30.279
<v Speaker 1>Because it came from the trusted site initially, the user

288
00:14:30.360 --> 00:14:32.360
<v Speaker 1>might not notice the switch exactly.

289
00:14:32.759 --> 00:14:35.480
<v Speaker 2>It makes the fish much harder to spot. It really

290
00:14:35.519 --> 00:14:37.679
<v Speaker 2>exploits that user trust in the original domain.

291
00:14:38.200 --> 00:14:42.600
<v Speaker 1>So how do ethical hackers track down these hidden potentially

292
00:14:42.720 --> 00:14:43.879
<v Speaker 1>malicious redirects.

293
00:14:44.080 --> 00:14:47.919
<v Speaker 2>Again, Bripsweet's proxy and spider tools are key. As you

294
00:14:48.000 --> 00:14:50.720
<v Speaker 2>browse the target application, you're keeping an eye out for

295
00:14:50.720 --> 00:14:53.600
<v Speaker 2>any HTTP responses that come back with a three xx

296
00:14:53.639 --> 00:14:56.799
<v Speaker 2>status code that three to one means a redirect is happening.

297
00:14:56.960 --> 00:14:59.720
<v Speaker 1>And once you spot a three xx redirect, then you.

298
00:14:59.600 --> 00:15:02.720
<v Speaker 2>Take that request over to Burp's repeater tool. There you

299
00:15:02.720 --> 00:15:05.080
<v Speaker 2>can manually tamper with the parameter that seems to be

300
00:15:05.080 --> 00:15:08.240
<v Speaker 2>controlling the redirect destination. If you can change it to

301
00:15:08.320 --> 00:15:10.960
<v Speaker 2>point to an external site you control, and the browser

302
00:15:11.000 --> 00:15:14.480
<v Speaker 2>successfully redirects there, you've confirmed the vulnerability, and.

303
00:15:14.440 --> 00:15:16.879
<v Speaker 1>If you find one, what's the fix you'd recommend?

304
00:15:17.080 --> 00:15:19.840
<v Speaker 2>Well, the best fix is usually to just avoid using

305
00:15:19.960 --> 00:15:24.320
<v Speaker 2>user controlled data in redirection logical together if possible. If

306
00:15:24.360 --> 00:15:27.720
<v Speaker 2>a redirect is necessary based on input, then use direct

307
00:15:27.840 --> 00:15:32.000
<v Speaker 2>hard coded links mapped to save values, or maintain a

308
00:15:32.120 --> 00:15:35.600
<v Speaker 2>very strict server side whitelist of allowed destination ur else.

309
00:15:35.759 --> 00:15:37.440
<v Speaker 1>Whitelisting sounds safer.

310
00:15:37.480 --> 00:15:41.480
<v Speaker 2>Definitely and absolutely crucial. Any user input that might influence

311
00:15:41.480 --> 00:15:45.080
<v Speaker 2>a redirect destination must be strongly validated. Check that it

312
00:15:45.120 --> 00:15:48.240
<v Speaker 2>starts with an expected trusted prefix like http dot your

313
00:15:48.279 --> 00:15:50.879
<v Speaker 2>site dot com and doesn't contain characters that could trick

314
00:15:50.919 --> 00:15:51.399
<v Speaker 2>the browser.

315
00:15:51.639 --> 00:15:55.519
<v Speaker 1>Okay, next up a real classic malicious file uploads. What's

316
00:15:55.559 --> 00:15:58.440
<v Speaker 1>the immediate danger if an attacker can successfully upload a

317
00:15:58.440 --> 00:15:59.000
<v Speaker 1>bad file?

318
00:15:59.279 --> 00:16:02.200
<v Speaker 2>Oh, the danger is huge. If an attacker can upload

319
00:16:02.200 --> 00:16:05.360
<v Speaker 2>a malicious file, especially something like a PHP script or

320
00:16:05.399 --> 00:16:07.519
<v Speaker 2>another executable file type, and then get the server to

321
00:16:07.559 --> 00:16:09.919
<v Speaker 2>run it, that can give them a significant foothold on

322
00:16:09.960 --> 00:16:12.200
<v Speaker 2>the system, leading to what It could lead to them

323
00:16:12.200 --> 00:16:15.320
<v Speaker 2>completely owning the system, as they say, getting full control,

324
00:16:15.679 --> 00:16:18.360
<v Speaker 2>or at the very least, maybe defacing the website changing

325
00:16:18.360 --> 00:16:21.600
<v Speaker 2>its content. It's basically a form of remote code execution.

326
00:16:22.200 --> 00:16:25.200
<v Speaker 2>You're potentially letting the attacker run their own programs directly

327
00:16:25.200 --> 00:16:25.840
<v Speaker 2>on your server.

328
00:16:26.120 --> 00:16:29.960
<v Speaker 1>Yikes. How does a poorly secured file upload form look

329
00:16:30.080 --> 00:16:31.200
<v Speaker 1>compared to a safe one?

330
00:16:31.279 --> 00:16:34.000
<v Speaker 2>An insecure one might be just a basic HTML form

331
00:16:34.080 --> 00:16:39.080
<v Speaker 2>form action upload, PHP method, posting type, multipart from data,

332
00:16:39.519 --> 00:16:41.879
<v Speaker 2>maybe with little or no checking happening on the server side.

333
00:16:41.919 --> 00:16:44.399
<v Speaker 2>It just sort of trusts whatever file the user sends.

334
00:16:44.159 --> 00:16:45.320
<v Speaker 1>It as a secure one.

335
00:16:45.440 --> 00:16:48.440
<v Speaker 2>A secure site implements robust validation on the server after

336
00:16:48.480 --> 00:16:51.320
<v Speaker 2>the file arrives. It would check the file extension sure,

337
00:16:51.519 --> 00:16:53.679
<v Speaker 2>But more importantly, it would check the actual file type

338
00:16:53.679 --> 00:16:56.399
<v Speaker 2>based on its content, not just the name. Maybe scan

339
00:16:56.519 --> 00:16:59.080
<v Speaker 2>it from malware and sure it matches an allowed list

340
00:16:59.080 --> 00:17:02.879
<v Speaker 2>of types like only accepting JPEGs or PDFs, and reject

341
00:17:03.000 --> 00:17:06.240
<v Speaker 2>anything suspicious, especially executable scripts like PHP.

342
00:17:06.640 --> 00:17:09.400
<v Speaker 1>So how would an attacker try to bypass these checks?

343
00:17:09.400 --> 00:17:11.759
<v Speaker 1>In a test lab like DVWA.

344
00:17:12.119 --> 00:17:15.839
<v Speaker 2>They often rely on tricks and misconfigurations. For example, you

345
00:17:15.920 --> 00:17:19.519
<v Speaker 2>might try uploading a malicious PHP file containing commands like

346
00:17:19.640 --> 00:17:24.200
<v Speaker 2>slixick elsli to list files or mk to hacker to

347
00:17:24.240 --> 00:17:25.039
<v Speaker 2>create a directory.

348
00:17:25.160 --> 00:17:27.720
<v Speaker 1>But the server might block dot php files.

349
00:17:27.880 --> 00:17:30.240
<v Speaker 2>Right, so if the server only checks the last part

350
00:17:30.240 --> 00:17:32.440
<v Speaker 2>of the file name, you might try naming your file

351
00:17:32.559 --> 00:17:36.839
<v Speaker 2>something like shell dot php dot jpg. You hope the

352
00:17:36.839 --> 00:17:39.759
<v Speaker 2>server sees dot jpg and allows it, but maybe later

353
00:17:39.839 --> 00:17:42.480
<v Speaker 2>another part of the system interprets it as dot php

354
00:17:42.759 --> 00:17:44.119
<v Speaker 2>and executes it clever.

355
00:17:44.359 --> 00:17:44.839
<v Speaker 1>What else?

356
00:17:45.119 --> 00:17:47.960
<v Speaker 2>You'd also use burp Suite's repeater tool to modify the

357
00:17:48.000 --> 00:17:50.559
<v Speaker 2>request on the fly. You can change the content type

358
00:17:50.599 --> 00:17:53.519
<v Speaker 2>heater that the browser sends, maybe setting it to image jpg.

359
00:17:53.599 --> 00:17:55.839
<v Speaker 2>Even though you're uploading PHP code. You're trying to fool

360
00:17:55.880 --> 00:17:58.880
<v Speaker 2>the server side validation logic and if it works. If

361
00:17:58.880 --> 00:18:02.400
<v Speaker 2>it works, you might send see visible changes like website defacement,

362
00:18:02.680 --> 00:18:04.680
<v Speaker 2>or maybe you can navigate to a new directory like

363
00:18:04.759 --> 00:18:08.599
<v Speaker 2>hacker that your malicious script created that confirms your code executed.

364
00:18:09.079 --> 00:18:11.079
<v Speaker 2>It's definitely a game of cat mouse with the servers

365
00:18:11.160 --> 00:18:11.920
<v Speaker 2>validation rules.

366
00:18:12.160 --> 00:18:16.640
<v Speaker 1>Okay, let's shift slightly towards email security poisoning Sender Policy

367
00:18:16.680 --> 00:18:20.400
<v Speaker 1>Framework or SBF. Most of us just send and receive

368
00:18:20.440 --> 00:18:23.960
<v Speaker 1>emails without thinking much about this. What does SBF actually do?

369
00:18:24.640 --> 00:18:28.440
<v Speaker 2>SBF is a technical standard for email authentication. Its main

370
00:18:28.559 --> 00:18:31.680
<v Speaker 2>job is to help protect both email senders and recipients

371
00:18:31.799 --> 00:18:34.960
<v Speaker 2>from spam, from email spoofing where someone pretends to be

372
00:18:35.000 --> 00:18:37.160
<v Speaker 2>someone else, and from phishing attacks.

373
00:18:37.200 --> 00:18:38.000
<v Speaker 1>How does it do that?

374
00:18:38.400 --> 00:18:42.039
<v Speaker 2>It works by allowing a domain owner, like say, your company,

375
00:18:42.359 --> 00:18:44.960
<v Speaker 2>to publish a list of mail servers that are authorized

376
00:18:44.960 --> 00:18:47.920
<v Speaker 2>to send email on behalf of that domain. When an

377
00:18:47.960 --> 00:18:51.519
<v Speaker 2>email arrives, the receiving server checks the sender's IP address

378
00:18:51.839 --> 00:18:54.640
<v Speaker 2>against this published SBF record for the domain.

379
00:18:54.440 --> 00:18:56.559
<v Speaker 1>Sort of like a bouncer checking an ID against a

380
00:18:56.599 --> 00:18:57.119
<v Speaker 1>guest list.

381
00:18:57.200 --> 00:18:59.880
<v Speaker 2>That's a great analogy. Yeah, if the sending server isn't

382
00:18:59.880 --> 00:19:02.960
<v Speaker 2>all list, the receiving server can be suspicious and might

383
00:19:03.000 --> 00:19:05.759
<v Speaker 2>mark the email as spam or even rejected outright.

384
00:19:05.880 --> 00:19:08.839
<v Speaker 1>Why do we need this extra layer? Doesn't basic email

385
00:19:08.920 --> 00:19:09.839
<v Speaker 1>handle authentication?

386
00:19:10.240 --> 00:19:14.519
<v Speaker 2>That's good question. The fundamental email protocol SMTP is actually

387
00:19:14.599 --> 00:19:19.440
<v Speaker 2>quite old and well surprisingly trusting. It doesn't have strong

388
00:19:19.480 --> 00:19:23.000
<v Speaker 2>authentication built in. It's relatively easy for someone to forge

389
00:19:23.000 --> 00:19:24.440
<v Speaker 2>the from address on an email.

390
00:19:24.480 --> 00:19:26.680
<v Speaker 1>So SPF plugs that gap exactly.

391
00:19:26.920 --> 00:19:29.480
<v Speaker 2>It adds a much needed layer of verification on top

392
00:19:29.559 --> 00:19:31.279
<v Speaker 2>of the basic SMTP process.

393
00:19:31.359 --> 00:19:34.680
<v Speaker 1>Okay, so it's important, but does it have limitations? And

394
00:19:34.720 --> 00:19:36.559
<v Speaker 1>I hear about DMRC too, what's that about.

395
00:19:36.880 --> 00:19:40.319
<v Speaker 2>Yes, SPF definitely has limitations. Yeah. One major one is

396
00:19:40.319 --> 00:19:43.480
<v Speaker 2>that it doesn't actually validate the frumheader the address the

397
00:19:43.480 --> 00:19:46.839
<v Speaker 2>recipient ces and their email client. It checks the envelope from,

398
00:19:47.039 --> 00:19:49.119
<v Speaker 2>which is used more for routing behind the scenes.

399
00:19:49.359 --> 00:19:51.920
<v Speaker 1>Ah, so it might not stop spoofing of the visible

400
00:19:51.960 --> 00:19:53.000
<v Speaker 1>address correct.

401
00:19:53.279 --> 00:19:56.759
<v Speaker 2>Also, SPF can sometimes break when emails are legitimately forwarded

402
00:19:56.799 --> 00:19:58.839
<v Speaker 2>because the forwarding server might not be listed in the

403
00:19:58.839 --> 00:20:02.000
<v Speaker 2>original domains sp F record. That's where DMRC comes in.

404
00:20:02.079 --> 00:20:04.039
<v Speaker 1>What is dmrcad.

405
00:20:03.440 --> 00:20:07.680
<v Speaker 2>DMR, which stands for Domain based Message Authentication Reporting and Conformance,

406
00:20:08.000 --> 00:20:11.880
<v Speaker 2>builds upon both SPF and another standard called DKIM. It

407
00:20:11.920 --> 00:20:16.440
<v Speaker 2>provides much stronger protection against spoofing and fizzing. Crucially, DMR

408
00:20:16.480 --> 00:20:19.640
<v Speaker 2>allows domain owners to tell receiving servers exactly what to

409
00:20:19.680 --> 00:20:23.000
<v Speaker 2>do with emails that fail SPF or DKEM checks, like

410
00:20:23.279 --> 00:20:25.759
<v Speaker 2>quarantine them or reject them. And it provides really valuable

411
00:20:25.839 --> 00:20:28.319
<v Speaker 2>reports back to the domain owner about who is sending

412
00:20:28.359 --> 00:20:31.960
<v Speaker 2>email using their domain, helping them spot fraudulent activity.

413
00:20:31.680 --> 00:20:34.200
<v Speaker 1>So better protection and visibility. How would someone check if

414
00:20:34.200 --> 00:20:36.359
<v Speaker 1>their domain's SPF record is set up correctly?

415
00:20:36.400 --> 00:20:38.759
<v Speaker 2>They're easy to use online tools for that. Good examples

416
00:20:38.799 --> 00:20:42.680
<v Speaker 2>are Kidderman dot com, SPF validate dot html, or the

417
00:20:42.720 --> 00:20:45.480
<v Speaker 2>tools on mxtoolbox dot com. You just put in your

418
00:20:45.480 --> 00:20:48.880
<v Speaker 2>domain name say Sunjipsynha, dot fund, and these tools will

419
00:20:48.880 --> 00:20:51.359
<v Speaker 2>fetch and analyze its published SPF record. They'll show you

420
00:20:51.400 --> 00:20:54.200
<v Speaker 2>what it is like VSPF one plus A plus MX

421
00:20:54.200 --> 00:20:56.720
<v Speaker 2>plus IP four point nine, four point one three zero

422
00:20:56.720 --> 00:20:59.759
<v Speaker 2>point one nine, put one two four all and tell

423
00:20:59.799 --> 00:21:02.599
<v Speaker 2>you it looks correctly formated, helping you spot in years useful.

424
00:21:02.759 --> 00:21:06.079
<v Speaker 1>Okay, Next on our list, XML External Entity injection or XX.

425
00:21:06.519 --> 00:21:09.359
<v Speaker 1>Now many people know XML is a way to structure data,

426
00:21:09.440 --> 00:21:11.079
<v Speaker 1>right How does that lead to an attack?

427
00:21:11.400 --> 00:21:15.400
<v Speaker 2>Right? First, quick recap. XML is a markup language, software

428
00:21:15.440 --> 00:21:18.920
<v Speaker 2>and hardware independent used for storing and transporting data. It's

429
00:21:18.920 --> 00:21:22.079
<v Speaker 2>self descriptive, kind of like a structured text file, maybe

430
00:21:22.200 --> 00:21:24.559
<v Speaker 2>similar in concept to a database table in some ways.

431
00:21:24.759 --> 00:21:27.319
<v Speaker 1>Is it still used much? I hear more about JSON now.

432
00:21:27.640 --> 00:21:30.839
<v Speaker 2>Jason has definitely become more popular for webapis, but XML

433
00:21:30.880 --> 00:21:35.279
<v Speaker 2>is still very widely used, especially in enterprise systems, configuration files,

434
00:21:35.359 --> 00:21:39.039
<v Speaker 2>industry specific standards things like SOPU web services. It's definitely

435
00:21:39.039 --> 00:21:39.599
<v Speaker 2>not gone away.

436
00:21:39.640 --> 00:21:41.839
<v Speaker 1>And what's a DTD? You mentioned that in the context

437
00:21:41.880 --> 00:21:43.000
<v Speaker 1>of XML.

438
00:21:42.680 --> 00:21:47.240
<v Speaker 2>A DTD or document type definition basically defines the rules

439
00:21:47.240 --> 00:21:50.400
<v Speaker 2>for an XML document. It specifies what elements and attributes

440
00:21:50.440 --> 00:21:53.920
<v Speaker 2>are allowed, their structure, ensuring the XML is valid according

441
00:21:53.920 --> 00:21:55.039
<v Speaker 2>to a specific format.

442
00:21:55.240 --> 00:21:59.160
<v Speaker 1>Okay, so XML is just structured data. DTD defines the structure.

443
00:21:59.319 --> 00:22:01.920
<v Speaker 1>Where does the injection part and the danger come from?

444
00:22:02.039 --> 00:22:06.480
<v Speaker 2>The danger the XX injection happens when an application processes

445
00:22:06.599 --> 00:22:09.960
<v Speaker 2>XML input from an untrusted source and its XML parser

446
00:22:10.039 --> 00:22:13.559
<v Speaker 2>is configured insecurely. Specifically, it involves exploiting a feature of

447
00:22:13.720 --> 00:22:17.519
<v Speaker 2>XML parsers that allows XML documents to declare and include

448
00:22:17.799 --> 00:22:18.799
<v Speaker 2>external entities.

449
00:22:18.960 --> 00:22:21.799
<v Speaker 1>External entities like pulling in data from outside the main

450
00:22:21.920 --> 00:22:23.480
<v Speaker 1>XML file exactly.

451
00:22:24.359 --> 00:22:27.880
<v Speaker 2>An attacker can craft malicious XML input that defines an

452
00:22:27.960 --> 00:22:31.559
<v Speaker 2>external entity pointing to a sensitive resource like a local

453
00:22:31.599 --> 00:22:35.160
<v Speaker 2>file on the server. If the parser is vulnerable, it

454
00:22:35.240 --> 00:22:38.200
<v Speaker 2>might actually fetch and include the content of that file

455
00:22:38.599 --> 00:22:40.960
<v Speaker 2>right into the XML document being processed.

456
00:22:41.319 --> 00:22:44.279
<v Speaker 1>So they trick the parser into grabbing things it shouldn't like.

457
00:22:44.319 --> 00:22:45.200
<v Speaker 1>What kind of things?

458
00:22:45.400 --> 00:22:48.599
<v Speaker 2>Potentially, Yeah, this could allow them to view files from

459
00:22:48.599 --> 00:22:52.240
<v Speaker 2>the server's file system. I think configuration files, password files

460
00:22:52.279 --> 00:22:56.200
<v Speaker 2>like etc. Pass throught on Linux. It could also potentially

461
00:22:56.279 --> 00:22:58.960
<v Speaker 2>let them interfere with back end systems the application talks to,

462
00:22:59.519 --> 00:23:02.200
<v Speaker 2>or even low bunch attacks against other external systems from

463
00:23:02.279 --> 00:23:06.000
<v Speaker 2>the application server itself. It exploits how some standard XML

464
00:23:06.039 --> 00:23:09.839
<v Speaker 2>libraries handle these external entities, sometimes insecurely by default.

465
00:23:10.200 --> 00:23:13.359
<v Speaker 1>So it's about tricking the XML parser into becoming an

466
00:23:13.440 --> 00:23:16.319
<v Speaker 1>unwilling accomplice to fetch local files. Can you give a

467
00:23:16.359 --> 00:23:18.880
<v Speaker 1>concrete example of what that malicious XML might look like?

468
00:23:19.119 --> 00:23:22.960
<v Speaker 2>Sure, in a vulnerable app like utilidae or bupp, you

469
00:23:23.039 --> 00:23:25.880
<v Speaker 2>might inject something like this into an XML input field

470
00:23:26.240 --> 00:23:32.079
<v Speaker 2>doc typefood dot entity, xccsystem file dot ettc passwd barn

471
00:23:32.279 --> 00:23:35.960
<v Speaker 2>xebar Okay. Breaking that down, the doc type part defines

472
00:23:36.000 --> 00:23:40.400
<v Speaker 2>a new entity named XC. The system file dot icpasswd

473
00:23:41.000 --> 00:23:44.279
<v Speaker 2>tells the parser that the content of this XCS entity

474
00:23:44.559 --> 00:23:46.720
<v Speaker 2>is the content of the local file a setter pass.

475
00:23:47.119 --> 00:23:50.119
<v Speaker 2>Then later in the XML n XS tries to use

476
00:23:50.160 --> 00:23:50.920
<v Speaker 2>that entity, and.

477
00:23:50.880 --> 00:23:53.079
<v Speaker 1>If the application is vulnerable.

478
00:23:52.640 --> 00:23:55.160
<v Speaker 2>It will replace anx with the actual contents of the

479
00:23:55.160 --> 00:23:58.200
<v Speaker 2>ETSETA pass file, and often that content will get reflected

480
00:23:58.240 --> 00:24:01.000
<v Speaker 2>back in the applications response, letting the attacker see it.

481
00:24:01.000 --> 00:24:03.359
<v Speaker 2>It's a direct way to leak sensitive server information.

482
00:24:03.759 --> 00:24:07.640
<v Speaker 1>That's incredibly powerful access from just manipulating XML. How would

483
00:24:07.680 --> 00:24:11.039
<v Speaker 1>you automate finding these and maybe grabbing specific config.

484
00:24:10.680 --> 00:24:14.279
<v Speaker 2>Files For automation, you definitely turn to Burpsuite's Intruder tool again.

485
00:24:14.400 --> 00:24:15.960
<v Speaker 2>You can load it up with a list of pre

486
00:24:16.039 --> 00:24:18.839
<v Speaker 2>made XX payloads. There are great collections online like the

487
00:24:18.880 --> 00:24:21.200
<v Speaker 2>payloads all the things repository on GitHub, and.

488
00:24:21.160 --> 00:24:22.279
<v Speaker 1>Intruder tries all of them.

489
00:24:22.440 --> 00:24:27.400
<v Speaker 2>Yeah, Intruder will systematically send requests with these different XXX payloads,

490
00:24:27.720 --> 00:24:31.359
<v Speaker 2>targeting various parameters or parts of the XML input. It

491
00:24:31.400 --> 00:24:34.640
<v Speaker 2>automates the fuzzing process trying different techniques to read local

492
00:24:34.680 --> 00:24:37.960
<v Speaker 2>files like common config files, or interact with the system

493
00:24:38.160 --> 00:24:41.279
<v Speaker 2>while you monitor the responses for any signs of success

494
00:24:41.640 --> 00:24:43.799
<v Speaker 2>like leaked file contents appearing okay.

495
00:24:43.880 --> 00:24:49.000
<v Speaker 1>Moving on to command injection vulnerabilities. The sounds well, pretty direct,

496
00:24:49.079 --> 00:24:53.240
<v Speaker 1>like the attacker is literally typing commands. What's the danger

497
00:24:53.319 --> 00:24:53.759
<v Speaker 1>level here?

498
00:24:54.000 --> 00:24:58.440
<v Speaker 2>The danger level is extremely high critical, usually because these

499
00:24:58.519 --> 00:25:02.359
<v Speaker 2>vulnerabilities allow an attacker to execute arbitrary operating system OS

500
00:25:02.440 --> 00:25:06.000
<v Speaker 2>commands directly on the server that's hosting the web application.

501
00:25:06.279 --> 00:25:08.000
<v Speaker 1>So if they get command injection.

502
00:25:08.079 --> 00:25:11.920
<v Speaker 2>It's often game over. They can potentially compromise the entire application,

503
00:25:12.160 --> 00:25:16.000
<v Speaker 2>steal or destroy all its data, maybe install malware, pivot

504
00:25:16.079 --> 00:25:19.119
<v Speaker 2>to attack other internal systems, essentially take full control of

505
00:25:19.160 --> 00:25:22.000
<v Speaker 2>the server infrastructure. It's one of those impactful vulnerabilities you

506
00:25:22.000 --> 00:25:22.400
<v Speaker 2>can find.

507
00:25:22.640 --> 00:25:25.200
<v Speaker 1>How is that different from something like say code injection.

508
00:25:25.319 --> 00:25:26.160
<v Speaker 1>They sound similar.

509
00:25:26.359 --> 00:25:30.880
<v Speaker 2>That's a really key distinction. OS. Command injection specifically runs

510
00:25:30.920 --> 00:25:34.400
<v Speaker 2>commands at the operating system level, like LS to list

511
00:25:34.480 --> 00:25:38.480
<v Speaker 2>files on Linux, or deeron Windows, or even rmaarf to

512
00:25:38.519 --> 00:25:41.880
<v Speaker 2>wipe the disc. It's interacting directly with the server's.

513
00:25:41.559 --> 00:25:42.839
<v Speaker 1>Shell, whereas code injection.

514
00:25:43.240 --> 00:25:46.559
<v Speaker 2>Code injection executes attacker supplied code within the application's own

515
00:25:46.599 --> 00:25:51.079
<v Speaker 2>programming language environment. So maybe injecting malicious PHP code that

516
00:25:51.079 --> 00:25:54.599
<v Speaker 2>the PHP interpreter runs, or Java code or Python code.

517
00:25:54.599 --> 00:25:57.519
<v Speaker 2>Both are extremely severe, but they operate at slightly different

518
00:25:57.559 --> 00:25:58.720
<v Speaker 2>layers of the system stack.

519
00:25:59.119 --> 00:26:02.839
<v Speaker 1>Got it, and how do attackers actually manage to sneak

520
00:26:03.119 --> 00:26:05.720
<v Speaker 1>their OS commands in? How do they piggyback them onto

521
00:26:05.880 --> 00:26:06.720
<v Speaker 1>legitimate input?

522
00:26:06.960 --> 00:26:10.279
<v Speaker 2>They typically use command separators. These are special characters that

523
00:26:10.319 --> 00:26:13.519
<v Speaker 2>the operating system shell understands as meaning run another command.

524
00:26:14.039 --> 00:26:17.039
<v Speaker 2>Common ones on Linux Unix are the semi colon, pete mill,

525
00:26:17.079 --> 00:26:20.400
<v Speaker 2>the ampersandic candor runs in background, double ampersand and L

526
00:26:20.720 --> 00:26:23.920
<v Speaker 2>runs only if previous command succeeded. The pipe sends output

527
00:26:23.960 --> 00:26:26.440
<v Speaker 2>of one command to another, and double pipe runs only

528
00:26:26.440 --> 00:26:27.559
<v Speaker 2>if previous command failed.

529
00:26:27.599 --> 00:26:31.240
<v Speaker 1>So they might append l's to some normal input exactly.

530
00:26:31.480 --> 00:26:33.599
<v Speaker 2>For example, if an application has a feature to ping

531
00:26:33.680 --> 00:26:36.839
<v Speaker 2>and IP address and takes the IP from user input,

532
00:26:36.920 --> 00:26:41.200
<v Speaker 2>an attacker might provide one hundred point zero point zero

533
00:26:41.359 --> 00:26:44.599
<v Speaker 2>point one LS. The application might build the command ping

534
00:26:44.759 --> 00:26:47.720
<v Speaker 2>one to two point zero point zero point one LS,

535
00:26:48.119 --> 00:26:51.319
<v Speaker 2>the OS runs, the ping finishes, sees the semi colon,

536
00:26:51.480 --> 00:26:53.720
<v Speaker 2>and then just runs l's as a completely separate command.

537
00:26:53.720 --> 00:26:55.480
<v Speaker 2>They're chaining commands together clever.

538
00:26:55.920 --> 00:26:58.279
<v Speaker 1>So how would an ethical hacker discover this in a

539
00:26:58.359 --> 00:27:00.720
<v Speaker 1>lab setting? What's the A.

540
00:27:00.680 --> 00:27:03.759
<v Speaker 2>Common approach is using vulnerable features like maybe a DNS

541
00:27:03.839 --> 00:27:06.680
<v Speaker 2>look up page in an app like mutilitay, combined with

542
00:27:06.680 --> 00:27:09.960
<v Speaker 2>purp suites, repeater and intruder. You'd start experimenting in repeater,

543
00:27:10.000 --> 00:27:13.839
<v Speaker 2>injecting potential command separators in simple OS commands after legitimate input,

544
00:27:14.359 --> 00:27:16.319
<v Speaker 2>like trying eight point eight point eight point eight eight

545
00:27:16.440 --> 00:27:18.359
<v Speaker 2>or eight eight point eight point eight in one one.

546
00:27:18.319 --> 00:27:20.119
<v Speaker 1>Mean, just trying different separators and commands.

547
00:27:20.200 --> 00:27:22.400
<v Speaker 2>Yeah, and then you'd use intruder to automate this fuzzing.

548
00:27:22.720 --> 00:27:25.640
<v Speaker 2>You can provide lists of separators, commands, maybe even special

549
00:27:25.680 --> 00:27:29.559
<v Speaker 2>fuzzing markers like sex sixcpres to systematically try different combinations.

550
00:27:29.720 --> 00:27:32.559
<v Speaker 2>Then you carefully analyze the HTTP responses from the server

551
00:27:32.759 --> 00:27:35.160
<v Speaker 2>looking for what in the response you're looking for the

552
00:27:35.200 --> 00:27:38.240
<v Speaker 2>output of your injected commands. If you inject LS and

553
00:27:38.279 --> 00:27:41.319
<v Speaker 2>suddenly see a file listing in the HTML response, or

554
00:27:41.359 --> 00:27:44.720
<v Speaker 2>you injects and see user information like OD three to

555
00:27:44.759 --> 00:27:49.359
<v Speaker 2>three WWW data, you know you've found a command injection vulnerability.

556
00:27:49.519 --> 00:27:51.960
<v Speaker 2>You can use it to discover the OS type, running

557
00:27:52.079 --> 00:27:54.720
<v Speaker 2>user installed software, all sorts of useful info.

558
00:27:54.880 --> 00:27:57.559
<v Speaker 1>We've covered a lot of serious ground. Let's wrap up

559
00:27:57.599 --> 00:28:00.240
<v Speaker 1>the vulnerability section with two big ones each, m MAL

560
00:28:00.319 --> 00:28:04.480
<v Speaker 1>injection and sqel injection. First, HTML injection. How is this

561
00:28:04.519 --> 00:28:05.359
<v Speaker 1>one characterized?

562
00:28:05.640 --> 00:28:08.920
<v Speaker 2>HTML injection is often described as a rendering attack. It

563
00:28:09.000 --> 00:28:12.680
<v Speaker 2>basically means an attacker can inject arbitrary HTML code tags

564
00:28:12.680 --> 00:28:15.200
<v Speaker 2>like h one or imagy or even form into a

565
00:28:15.240 --> 00:28:18.759
<v Speaker 2>web page, and that injected HTML gets rendered in display

566
00:28:18.839 --> 00:28:20.079
<v Speaker 2>to other users.

567
00:28:19.759 --> 00:28:22.079
<v Speaker 1>So it messes with how the page looks. What are

568
00:28:22.119 --> 00:28:23.039
<v Speaker 1>the actual risks?

569
00:28:23.160 --> 00:28:25.880
<v Speaker 2>Well? Compared to command injection, it might seem less risky

570
00:28:25.920 --> 00:28:29.079
<v Speaker 2>for say, direct data theft, but it can seriously damage

571
00:28:29.160 --> 00:28:32.799
<v Speaker 2>website's reputation by defacing its appearance. More critically, it can

572
00:28:32.880 --> 00:28:36.039
<v Speaker 2>often be a stepping stone to more severe attacks. For instance,

573
00:28:36.359 --> 00:28:40.119
<v Speaker 2>an attacker could inject a fake login form using HTML injection.

574
00:28:40.599 --> 00:28:43.400
<v Speaker 2>That form might look legitimate, but it actually posts the

575
00:28:43.480 --> 00:28:47.640
<v Speaker 2>user's credentials to the attacker server. Or they might inject

576
00:28:47.759 --> 00:28:51.160
<v Speaker 2>HTML that helps them steal session cookies, potentially leading to

577
00:28:51.200 --> 00:28:54.519
<v Speaker 2>a full cross site scripting EXSS attack if they can

578
00:28:54.559 --> 00:28:56.359
<v Speaker 2>also inject script tags.

579
00:28:56.559 --> 00:28:59.640
<v Speaker 1>So it's about manipulating what the user sees and potentially

580
00:28:59.640 --> 00:29:02.960
<v Speaker 1>setting them up for something worse. How is it usually

581
00:29:03.000 --> 00:29:04.519
<v Speaker 1>found and what's the defense.

582
00:29:04.720 --> 00:29:07.200
<v Speaker 2>You can often find it manually in test apps, like

583
00:29:07.240 --> 00:29:10.720
<v Speaker 2>maybe a stored blog page in bwapp. You try injecting

584
00:29:10.759 --> 00:29:13.880
<v Speaker 2>simple HTML tags like btestp or maybe a small image

585
00:29:13.880 --> 00:29:16.200
<v Speaker 2>tag and see if it actually renders on the page

586
00:29:16.200 --> 00:29:19.079
<v Speaker 2>when you view it later and prevention. Prevention comes down

587
00:29:19.160 --> 00:29:23.079
<v Speaker 2>to robust input sanitization. Again, any user supplied input that's

588
00:29:23.079 --> 00:29:24.680
<v Speaker 2>going to be displayed back on a page needs to

589
00:29:24.720 --> 00:29:28.440
<v Speaker 2>have potentially dangerous HTML characters properly escaped or stripped out

590
00:29:28.519 --> 00:29:32.599
<v Speaker 2>before it's rendered. Using libraries designed for this is key. Also,

591
00:29:32.680 --> 00:29:36.440
<v Speaker 2>implementing a strong content security policy or CSP is crucial.

592
00:29:36.480 --> 00:29:37.720
<v Speaker 1>What does CSP do here?

593
00:29:38.000 --> 00:29:43.720
<v Speaker 2>CSP tells the user's browser exactly what sources of content, scripts, images, styles, etc.

594
00:29:44.279 --> 00:29:46.839
<v Speaker 2>Are allowed to be loaded and executed for your website.

595
00:29:47.200 --> 00:29:49.720
<v Speaker 2>It can help mitigate the impact of injection attacks even

596
00:29:49.759 --> 00:29:53.319
<v Speaker 2>if some malicious HTML or script manages to get through

597
00:29:53.359 --> 00:29:55.200
<v Speaker 2>the initial sanitization right.

598
00:29:55.319 --> 00:30:00.319
<v Speaker 1>And finally, the big one SQL injection or sequel sort

599
00:30:00.359 --> 00:30:03.400
<v Speaker 1>of this, it sounds incredibly serious. What's the fundamental idea.

600
00:30:03.680 --> 00:30:07.720
<v Speaker 2>It is extremely serious. Sequel is a web security vulnerability

601
00:30:08.000 --> 00:30:10.880
<v Speaker 2>that allows an attacker to interfere with the database queries

602
00:30:10.880 --> 00:30:15.680
<v Speaker 2>that an application makes. Essentially, the attacker crafts malicious input that,

603
00:30:15.960 --> 00:30:19.200
<v Speaker 2>when included in a database query by the application, changes

604
00:30:19.200 --> 00:30:21.480
<v Speaker 2>the query's logic in a way the attacker controls.

605
00:30:21.519 --> 00:30:24.519
<v Speaker 1>You're basically talking directly to the database through the web

606
00:30:24.559 --> 00:30:25.839
<v Speaker 1>application in effect.

607
00:30:26.000 --> 00:30:29.400
<v Speaker 2>Yes, by manipulating the input, they trick the application into

608
00:30:29.440 --> 00:30:31.960
<v Speaker 2>sending malicious sequel commands to the database on their.

609
00:30:31.880 --> 00:30:35.880
<v Speaker 1>Behalf and potential impact If they succeed, what can they do? Oh?

610
00:30:35.920 --> 00:30:41.039
<v Speaker 2>The consequences are typically catastrophic. Attackers can potentially read sensitive

611
00:30:41.079 --> 00:30:46.160
<v Speaker 2>data from the database, the user credentials, personal information, credit

612
00:30:46.160 --> 00:30:49.279
<v Speaker 2>card numbers. They can modify or delete data. They can

613
00:30:49.359 --> 00:30:54.279
<v Speaker 2>often bypass authentication mechanisms entirely, maybe gaining administrative access to

614
00:30:54.319 --> 00:30:54.920
<v Speaker 2>the application.

615
00:30:55.319 --> 00:30:56.480
<v Speaker 1>Can it get worse than that?

616
00:30:57.400 --> 00:31:00.440
<v Speaker 2>Yes, Depending on the database configuration and permission, they might

617
00:31:00.480 --> 00:31:03.559
<v Speaker 2>even be able to execute operating system commands on the

618
00:31:03.640 --> 00:31:08.240
<v Speaker 2>database server itself, completely compromising the underlying infrastructure, or launch

619
00:31:08.279 --> 00:31:11.079
<v Speaker 2>denial of service attacks that bring down the database and

620
00:31:11.119 --> 00:31:14.920
<v Speaker 2>the application. It's a gateway to the Crown jewels usually Wow.

621
00:31:15.319 --> 00:31:17.799
<v Speaker 1>You mentioned bypassing authentication. Can you give an example of

622
00:31:17.799 --> 00:31:20.240
<v Speaker 1>how that works? It sounds almost too simple, It.

623
00:31:20.200 --> 00:31:23.440
<v Speaker 2>Often is surprisingly simple with basic vulnerabilities. Let's say you

624
00:31:23.440 --> 00:31:25.759
<v Speaker 2>have a log in form that takes a username in password.

625
00:31:26.200 --> 00:31:29.200
<v Speaker 2>A vulnerable application might build a SQL query like select

626
00:31:29.200 --> 00:31:33.039
<v Speaker 2>from users where a username improtucer and password.

627
00:31:33.160 --> 00:31:34.480
<v Speaker 1>Okay, standard log in query.

628
00:31:34.759 --> 00:31:37.359
<v Speaker 2>Now, an attacker might enter something like R one one

629
00:31:37.400 --> 00:31:40.799
<v Speaker 2>into the username field and maybe anything in the password field.

630
00:31:41.279 --> 00:31:44.799
<v Speaker 2>The application might then construct the query select from users

631
00:31:44.799 --> 00:31:47.160
<v Speaker 2>where username or one in password or whatever.

632
00:31:47.440 --> 00:31:48.720
<v Speaker 1>What does the R one one do?

633
00:31:49.039 --> 00:31:51.960
<v Speaker 2>Well? One one is always true, so the wear clause

634
00:31:51.960 --> 00:31:56.079
<v Speaker 2>becomes where username equal true. Since anything or true is

635
00:31:56.119 --> 00:31:59.240
<v Speaker 2>always true, the condition matches every row in the user's table.

636
00:32:00.079 --> 00:32:02.559
<v Speaker 2>The at the end is a comment signal and SQL

637
00:32:02.720 --> 00:32:05.039
<v Speaker 2>often making the database ignore the rest of the line,

638
00:32:05.319 --> 00:32:06.759
<v Speaker 2>including the password.

639
00:32:06.400 --> 00:32:10.319
<v Speaker 1>Check, so the query just returns all users exactly.

640
00:32:09.960 --> 00:32:12.799
<v Speaker 2>And often the application code will just log in the

641
00:32:12.799 --> 00:32:15.559
<v Speaker 2>first user returned by the query, which is frequently the

642
00:32:15.559 --> 00:32:18.920
<v Speaker 2>administrator account. Boom, They're logged in as admin without needing

643
00:32:18.960 --> 00:32:21.839
<v Speaker 2>a password. It's the digital equivalent of a skeleton key.

644
00:32:21.880 --> 00:32:25.200
<v Speaker 1>That's incredibly effective for such a simple input. Now, beyond

645
00:32:25.240 --> 00:32:27.759
<v Speaker 1>logging in, how do attackers use SQL to explore the

646
00:32:27.839 --> 00:32:31.200
<v Speaker 1>database and steal data? You mentioned a tool called school map.

647
00:32:31.400 --> 00:32:34.240
<v Speaker 2>Right once you've confirmed in SQL injection, point maybe using

648
00:32:34.279 --> 00:32:37.319
<v Speaker 2>burp suite to find where input affects the database. School

649
00:32:37.359 --> 00:32:41.279
<v Speaker 2>Map is the go to tool for automating the exploitation. It's

650
00:32:41.319 --> 00:32:44.400
<v Speaker 2>incredibly powerful and comes pre installed with Cali Linux.

651
00:32:44.440 --> 00:32:45.880
<v Speaker 1>How does it work? What can it do?

652
00:32:46.079 --> 00:32:49.599
<v Speaker 2>You can basically feed school Map a saved AGTTP request

653
00:32:49.599 --> 00:32:53.759
<v Speaker 2>from burpsuite that contains the vulnerable parameter using the alve flag.

654
00:32:54.279 --> 00:32:56.599
<v Speaker 2>Then you give it commands. It can automatically figure out

655
00:32:56.599 --> 00:32:59.359
<v Speaker 2>what type of database is on the back end my SQL,

656
00:32:59.440 --> 00:33:03.799
<v Speaker 2>Microsoft's server, Postgrescool, Oracle, et cetera, often by fingerprinting the

657
00:33:03.880 --> 00:33:06.559
<v Speaker 2>responses or grabbing the database.

658
00:33:06.119 --> 00:33:09.680
<v Speaker 1>Banner so it identifies a target first. Then what Then you.

659
00:33:09.680 --> 00:33:12.359
<v Speaker 2>Can tell it to list all the databases available you Wise,

660
00:33:12.680 --> 00:33:15.039
<v Speaker 2>once you pick a database of interest, say one name

661
00:33:15.119 --> 00:33:17.640
<v Speaker 2>Noah SIP, you can list all the tables within that

662
00:33:17.720 --> 00:33:19.640
<v Speaker 2>database no aspit tables and.

663
00:33:19.599 --> 00:33:22.000
<v Speaker 1>Find interesting tables like credit cards exactly.

664
00:33:22.519 --> 00:33:24.799
<v Speaker 2>Once you find an interesting table like credit cards, you

665
00:33:24.839 --> 00:33:27.319
<v Speaker 2>can list all the columns within that table dat d no,

666
00:33:27.480 --> 00:33:29.880
<v Speaker 2>ask betty t credit cards columns to see what kind

667
00:33:29.880 --> 00:33:33.720
<v Speaker 2>of data it holds, maybe CC number or CCVE expire date, and.

668
00:33:33.680 --> 00:33:37.200
<v Speaker 1>The final step getting the actual data yep.

669
00:33:37.720 --> 00:33:40.519
<v Speaker 2>The final step is to tell school map to dump

670
00:33:40.559 --> 00:33:43.640
<v Speaker 2>all the data from that specific table DATCHI knee no

671
00:33:43.799 --> 00:33:48.039
<v Speaker 2>OSC datchnee credit cards dump. It will then use various

672
00:33:48.039 --> 00:33:51.599
<v Speaker 2>SEQL injection techniques to extract every row and column from

673
00:33:51.640 --> 00:33:54.240
<v Speaker 2>that table and display it right there for you. It

674
00:33:54.279 --> 00:33:58.119
<v Speaker 2>automates what would be an incredibly tedious manual process potentially

675
00:33:58.200 --> 00:34:02.000
<v Speaker 2>revealing highly sensitive information. It's an ethical hacker's best friend

676
00:34:02.039 --> 00:34:04.400
<v Speaker 2>when it comes to exploring databases via seqel.

677
00:34:04.640 --> 00:34:08.840
<v Speaker 3>Wow, that is incredibly comprehensive, going from finding a small

678
00:34:08.840 --> 00:34:12.360
<v Speaker 3>flaw to potentially dumping the entire database. What an eye

679
00:34:12.400 --> 00:34:14.800
<v Speaker 3>opening journey through just some of these web vulnerabilities and

680
00:34:14.800 --> 00:34:17.079
<v Speaker 3>the tools used to find them. It really hammers home

681
00:34:17.119 --> 00:34:19.360
<v Speaker 3>how many potential cracks there can be in the digital

682
00:34:19.360 --> 00:34:21.280
<v Speaker 3>foundations we rely on constantly.

683
00:34:21.440 --> 00:34:23.840
<v Speaker 2>It truly is a dynamic field, isn't it. It's constantly

684
00:34:23.880 --> 00:34:27.440
<v Speaker 2>evolving the world of web security and bug bounty hunting specifically.

685
00:34:27.599 --> 00:34:29.679
<v Speaker 2>It just demands continuous learning. You have to keep up

686
00:34:29.719 --> 00:34:33.360
<v Speaker 2>with research adapt quickly. New threats, new vulnerability types, new

687
00:34:33.360 --> 00:34:35.320
<v Speaker 2>attack techniques emerge all the.

688
00:34:35.280 --> 00:34:38.679
<v Speaker 1>Time, so what worked yesterday might not be enough today exactly.

689
00:34:38.960 --> 00:34:42.760
<v Speaker 2>Success in this area really comes from well, a deep curiosity,

690
00:34:43.039 --> 00:34:46.519
<v Speaker 2>maybe even a bit of obsession, and definitely persistence in determination.

691
00:34:47.119 --> 00:34:49.039
<v Speaker 2>You have to be willing to dig deep and always

692
00:34:49.079 --> 00:34:50.599
<v Speaker 2>try to stay one step ahead.

693
00:34:50.880 --> 00:34:53.239
<v Speaker 1>So a final thought for our listeners, then, in this

694
00:34:53.320 --> 00:34:56.800
<v Speaker 1>world of ever evolving digital threats, how much do you

695
00:34:56.880 --> 00:34:59.239
<v Speaker 1>really know about the hidden weaknesses and the websites and

696
00:34:59.280 --> 00:35:01.960
<v Speaker 1>applications you interact with every single day?

697
00:35:03.199 --> 00:35:05.840
<v Speaker 2>And maybe what might that knowledge compel you to explore

698
00:35:05.920 --> 00:35:06.159
<v Speaker 2>next