WEBVTT

1
00:00:00.120 --> 00:00:03.319
<v Speaker 1>Have you ever stopped to think about this, getting paid,

2
00:00:03.799 --> 00:00:09.080
<v Speaker 1>like actual money by huge companies like Facebook or Microsoft

3
00:00:10.000 --> 00:00:12.160
<v Speaker 1>just for finding bugs in their systems.

4
00:00:12.599 --> 00:00:15.560
<v Speaker 2>Yeah, legally it sounds a bit like science fiction, doesn't it.

5
00:00:15.839 --> 00:00:18.679
<v Speaker 2>But it's totally real. There's this whole community out there,

6
00:00:19.120 --> 00:00:21.160
<v Speaker 2>ethical hackers, white hats, whatever you want to.

7
00:00:21.160 --> 00:00:23.359
<v Speaker 1>Call them, and they're making serious money sometimes.

8
00:00:23.440 --> 00:00:26.800
<v Speaker 2>Oh yeah, definitely. Some hunters pull in thousands, even tens

9
00:00:26.800 --> 00:00:29.719
<v Speaker 2>of thousands in a year, and they're playing a really

10
00:00:29.760 --> 00:00:32.799
<v Speaker 2>crucial role in making the Internet safer.

11
00:00:33.039 --> 00:00:36.320
<v Speaker 1>Absolutely, so welcome everyone to our deep dive. Today. We're

12
00:00:36.359 --> 00:00:40.039
<v Speaker 1>plunging into the pretty fascinating world of bug bounty hunting.

13
00:00:40.200 --> 00:00:42.320
<v Speaker 2>It's more than just finding glitches, isn't it?

14
00:00:42.439 --> 00:00:45.200
<v Speaker 1>Way more? It's like being a digital detective, a force

15
00:00:45.240 --> 00:00:49.000
<v Speaker 1>for good and cybersecurity. Today we're digging into the key

16
00:00:49.039 --> 00:00:52.719
<v Speaker 1>ideas from Bug Bounty Hunting Essentials by Carlos Alazano and

17
00:00:52.759 --> 00:00:53.520
<v Speaker 1>Shamir Amir.

18
00:00:53.840 --> 00:00:55.960
<v Speaker 2>Great book, really practical stuff in there.

19
00:00:56.079 --> 00:00:58.719
<v Speaker 1>Yeah, and our mission here is to give you the shortcut,

20
00:00:58.840 --> 00:01:01.880
<v Speaker 1>the core knowledge for their work, so you walk away

21
00:01:02.000 --> 00:01:03.880
<v Speaker 1>knowing what this field is all about, whether you're just

22
00:01:03.960 --> 00:01:06.359
<v Speaker 1>curious or maybe even thinking about it as a path.

23
00:01:06.560 --> 00:01:11.480
<v Speaker 2>So at its heart bug bounty hunting, it's really about

24
00:01:11.560 --> 00:01:15.040
<v Speaker 2>formalizing this whole process, right, It's a structured way to

25
00:01:15.159 --> 00:01:20.680
<v Speaker 2>find vulnerabilities flaws basically in applications, web apps, mobile apps, software.

26
00:01:20.280 --> 00:01:23.359
<v Speaker 1>And companies actually pay for this. They offer rewards bounties exactly.

27
00:01:23.359 --> 00:01:25.879
<v Speaker 2>They give bounties to hackers who find these problems and

28
00:01:26.280 --> 00:01:29.400
<v Speaker 2>crucially report them responsibly through the proper channels.

29
00:01:29.519 --> 00:01:32.959
<v Speaker 1>Well wait, don't be companies already have huge security teams

30
00:01:33.000 --> 00:01:33.680
<v Speaker 1>doing this stuff.

31
00:01:33.680 --> 00:01:38.400
<v Speaker 2>Internally they do, absolutely, but internal teams, well, they can

32
00:01:38.439 --> 00:01:41.840
<v Speaker 2>benefit massively from having outsiders look at things, you know,

33
00:01:42.079 --> 00:01:44.920
<v Speaker 2>real world hackers with different perspectives, like.

34
00:01:44.920 --> 00:01:48.040
<v Speaker 1>An external audit, but way more dynamic kind of.

35
00:01:48.159 --> 00:01:51.760
<v Speaker 2>Yeah. These are often called vulnerability rewards programs or vrps.

36
00:01:52.079 --> 00:01:57.000
<v Speaker 2>They usually manage through these special platforms, vulnerability coordination platforms.

37
00:01:57.200 --> 00:02:01.439
<v Speaker 2>It's essentially crowdsourcing. Security companies pay individual hackers for finding

38
00:02:01.519 --> 00:02:05.079
<v Speaker 2>specific bugs, leveraging this huge global pool of talent.

39
00:02:05.280 --> 00:02:07.680
<v Speaker 1>It really sounds like a marketplace for security skills. So

40
00:02:07.879 --> 00:02:09.919
<v Speaker 1>where does this actually happen? Where are these hackers go

41
00:02:10.000 --> 00:02:10.719
<v Speaker 1>looking for work?

42
00:02:11.000 --> 00:02:14.479
<v Speaker 2>The book highlights the big players. You've got hacker one

43
00:02:14.599 --> 00:02:16.319
<v Speaker 2>that was one of the first and it's still massive.

44
00:02:16.639 --> 00:02:18.360
<v Speaker 2>Then there's bug crowd Cobalt.

45
00:02:18.400 --> 00:02:21.560
<v Speaker 1>Cobolt's the one known for PTS right penetration testing as

46
00:02:21.599 --> 00:02:22.319
<v Speaker 1>a service.

47
00:02:22.080 --> 00:02:25.280
<v Speaker 2>That's the one, Yeah, PTS and Sinnak is another major platform.

48
00:02:25.319 --> 00:02:29.240
<v Speaker 2>They handle everything they're reporting, verifying the bugs, managing the payouts.

49
00:02:29.520 --> 00:02:31.479
<v Speaker 1>Okay, so you sign up for one of these platforms.

50
00:02:31.560 --> 00:02:35.360
<v Speaker 1>Are all the hunting grounds the programs open to everyone?

51
00:02:35.520 --> 00:02:39.960
<v Speaker 2>Ah, good question. There's a key difference. You have public programs,

52
00:02:40.000 --> 00:02:42.159
<v Speaker 2>which yeah, are generally open to anyone who signs up

53
00:02:42.159 --> 00:02:44.680
<v Speaker 2>on the platform. They list the rules, what's in scope,

54
00:02:44.719 --> 00:02:48.319
<v Speaker 2>what's out, the bounty levels, all public.

55
00:02:48.080 --> 00:02:49.000
<v Speaker 1>And the alternative.

56
00:02:49.120 --> 00:02:51.879
<v Speaker 2>Then you have private programs either invite only. You usually

57
00:02:51.960 --> 00:02:54.680
<v Speaker 2>need a proven track record, good stats on the platform,

58
00:02:54.719 --> 00:02:57.199
<v Speaker 2>maybe specific skills the company is looking for.

59
00:02:57.639 --> 00:03:00.560
<v Speaker 1>So reputation matters a lot hugely.

60
00:03:01.000 --> 00:03:04.560
<v Speaker 2>Private programs often focus on specific maybe newer parts of

61
00:03:04.560 --> 00:03:08.000
<v Speaker 2>an application, and they want experienced eyes on it, trying

62
00:03:08.039 --> 00:03:10.199
<v Speaker 2>to avoid a flood of low severity reports.

63
00:03:10.520 --> 00:03:13.759
<v Speaker 1>So how do these platforms and companies actually measure a

64
00:03:13.840 --> 00:03:15.960
<v Speaker 1>hunter's reputation? What are they looking at?

65
00:03:16.400 --> 00:03:19.319
<v Speaker 2>It's all about the stats. The book mentions three key

66
00:03:19.360 --> 00:03:21.960
<v Speaker 2>ones signal impact and accuracy.

67
00:03:22.039 --> 00:03:23.080
<v Speaker 1>Okay, break those down.

68
00:03:23.319 --> 00:03:27.520
<v Speaker 2>Signal signal is basically a measure of how valid your

69
00:03:27.560 --> 00:03:31.680
<v Speaker 2>reports are. Too many invalid or duplicate reports, your signal

70
00:03:31.719 --> 00:03:33.960
<v Speaker 2>goes down. It's like a noise filter for the companies.

71
00:03:34.240 --> 00:03:37.680
<v Speaker 1>Makes sense. Impact that sounds like the severity pretty much.

72
00:03:37.800 --> 00:03:40.319
<v Speaker 2>It reflects the average bounty amount you've been awarded per

73
00:03:40.400 --> 00:03:44.400
<v Speaker 2>valid report. Higher impact generally means you're finding more critical

74
00:03:44.520 --> 00:03:47.840
<v Speaker 2>vulnerabilities and accuracy. That's your hit rate, the percentage of

75
00:03:47.879 --> 00:03:50.680
<v Speaker 2>your reports that get accepted, divided by the total number

76
00:03:50.719 --> 00:03:54.159
<v Speaker 2>you submit. It so like ninety one percent accuracy. That

77
00:03:54.199 --> 00:03:58.560
<v Speaker 2>tells a company you're consistently finding real valid issues.

78
00:03:58.639 --> 00:04:01.840
<v Speaker 1>Right, So that reputation system is key for trust. Okay,

79
00:04:01.919 --> 00:04:04.759
<v Speaker 1>let's shift hears Someone listening might be thinking this sounds cool,

80
00:04:04.800 --> 00:04:07.800
<v Speaker 1>But where do I even start. Do you absolutely need

81
00:04:07.840 --> 00:04:10.360
<v Speaker 1>a string of security SERTs or a fancy degree.

82
00:04:10.520 --> 00:04:12.879
<v Speaker 2>That's one of the biggest myths the book tackles head on.

83
00:04:13.240 --> 00:04:17.439
<v Speaker 2>You don't need formal certifications or a specific degree. Age

84
00:04:17.519 --> 00:04:18.720
<v Speaker 2>isn't really a factor either.

85
00:04:18.920 --> 00:04:21.519
<v Speaker 1>Really, that's quite empowering it is.

86
00:04:21.959 --> 00:04:25.439
<v Speaker 2>But and this is a big butt, you absolutely do

87
00:04:25.519 --> 00:04:29.000
<v Speaker 2>need a deep understanding of how applications are built, how

88
00:04:29.000 --> 00:04:32.360
<v Speaker 2>they work, and where the common security weaknesses lie.

89
00:04:32.439 --> 00:04:35.639
<v Speaker 1>So less about the paper, more about the practical knowledge exactly.

90
00:04:35.759 --> 00:04:39.560
<v Speaker 2>The real starting point the kickstart is learning web and

91
00:04:39.639 --> 00:04:42.199
<v Speaker 2>mobile application technologies inside and out.

92
00:04:42.319 --> 00:04:46.439
<v Speaker 1>Okay, So if degrees aren't the gatekeepers, what's the actual roadmap?

93
00:04:46.439 --> 00:04:48.639
<v Speaker 1>How does someone build that practical knowledge?

94
00:04:48.720 --> 00:04:52.120
<v Speaker 2>It's a hands on journey, The book suggests, starting by reading.

95
00:04:52.480 --> 00:04:55.240
<v Speaker 2>Get good books on website hacking, then maybe mobile hacking.

96
00:04:55.519 --> 00:04:57.600
<v Speaker 2>Focus on areas that genuinely interest you.

97
00:04:57.839 --> 00:04:59.519
<v Speaker 1>Then what just reading isn't enough? Right?

98
00:04:59.560 --> 00:05:04.000
<v Speaker 2>Definitely? Step two is practice. Set up virtual environments with

99
00:05:04.079 --> 00:05:07.800
<v Speaker 2>deliberately vulnerable applications. There are loads available and test the

100
00:05:07.839 --> 00:05:10.199
<v Speaker 2>techniques you're reading about. Break things safely?

101
00:05:10.360 --> 00:05:12.680
<v Speaker 1>Okay, read practice? What else?

102
00:05:12.680 --> 00:05:16.040
<v Speaker 2>Read reports, look at the proof of concepts, the polsies

103
00:05:16.240 --> 00:05:19.759
<v Speaker 2>that other successful hunters have published. The security community is

104
00:05:19.800 --> 00:05:24.279
<v Speaker 2>surprisingly open. Blogs like hacker one's own or famous researchers

105
00:05:24.319 --> 00:05:26.879
<v Speaker 2>like Franz Rosen. They share a ton, learning from the

106
00:05:26.879 --> 00:05:30.720
<v Speaker 2>winds of others precisely, and finally connect with people, network,

107
00:05:30.920 --> 00:05:34.199
<v Speaker 2>join online communities, maybe even team up with other learners,

108
00:05:34.480 --> 00:05:38.120
<v Speaker 2>bouncing ideas off others that can really accelerate.

109
00:05:37.639 --> 00:05:40.879
<v Speaker 1>Things that sounds like a solid plan. Beyond the technical

110
00:05:40.959 --> 00:05:44.519
<v Speaker 1>learning curve, What about mindset? Are there specific rules or

111
00:05:44.560 --> 00:05:47.079
<v Speaker 1>ways of thinking that help people succeed here?

112
00:05:47.279 --> 00:05:51.279
<v Speaker 2>Oh? Absolutely, mindset is huge. The book has some crucial pointers.

113
00:05:51.560 --> 00:05:55.279
<v Speaker 2>First off, start small, seriously, don't try to hack Google

114
00:05:55.360 --> 00:05:56.639
<v Speaker 2>or Microsoft on your first.

115
00:05:56.480 --> 00:05:58.920
<v Speaker 1>Day out, because they're like fortresses.

116
00:05:58.360 --> 00:06:02.360
<v Speaker 2>Exactly, they have armies of security people. Instead, look for programs,

117
00:06:02.399 --> 00:06:05.040
<v Speaker 2>maybe smaller ones or parts of bigger programs, that get

118
00:06:05.120 --> 00:06:08.519
<v Speaker 2>less attention. Find those bounties that go ignored. As the

119
00:06:08.560 --> 00:06:09.360
<v Speaker 2>book puts.

120
00:06:09.079 --> 00:06:12.759
<v Speaker 1>It, find the path less traveled makes sense. What else?

121
00:06:13.079 --> 00:06:17.879
<v Speaker 2>Approach with clarity before you even start poking around. Really

122
00:06:17.959 --> 00:06:20.839
<v Speaker 2>understand what the application is supposed to do, What are

123
00:06:20.879 --> 00:06:24.480
<v Speaker 2>its features, what can different users do? Check the documentation

124
00:06:24.560 --> 00:06:29.439
<v Speaker 2>if it's available, Know your target right, and keep expectations low,

125
00:06:29.600 --> 00:06:32.360
<v Speaker 2>especially at first. Don't go in thinking you'll find a

126
00:06:32.399 --> 00:06:35.519
<v Speaker 2>critical bug where thousands in your first week. Report what

127
00:06:35.639 --> 00:06:39.480
<v Speaker 2>you find, learn from it, move on. Develop a mindset

128
00:06:39.480 --> 00:06:42.879
<v Speaker 2>of just hunting bugs, not hunting bugs in a matter

129
00:06:42.959 --> 00:06:43.399
<v Speaker 2>of hours.

130
00:06:43.480 --> 00:06:45.439
<v Speaker 1>Patients and persistence again totally.

131
00:06:45.519 --> 00:06:49.279
<v Speaker 2>Yeah. Also, really learn the vulnerabilities, understand why they happen

132
00:06:49.360 --> 00:06:51.920
<v Speaker 2>in the code before you try exploiting them and stay

133
00:06:52.000 --> 00:06:55.959
<v Speaker 2>up to date. Things change constantly, new frameworks, new attack technique.

134
00:06:56.000 --> 00:06:57.639
<v Speaker 1>It's a continuous learning game.

135
00:06:57.600 --> 00:07:00.959
<v Speaker 2>Always and remember, even finding something that doesn't qualify for

136
00:07:01.000 --> 00:07:04.199
<v Speaker 2>a bounty, that's still valuable experience. You learn something, and finally,

137
00:07:04.399 --> 00:07:06.319
<v Speaker 2>think about chaining vulnerabilities.

138
00:07:06.360 --> 00:07:07.720
<v Speaker 1>Combining smaller issues.

139
00:07:07.879 --> 00:07:11.199
<v Speaker 2>Yes, sometimes two or three low impact bugs combined can

140
00:07:11.240 --> 00:07:14.399
<v Speaker 2>create a critical risk. Look for the biggest overall impact,

141
00:07:14.480 --> 00:07:15.879
<v Speaker 2>not just isolated flaws.

142
00:07:16.079 --> 00:07:19.720
<v Speaker 1>Okay, so you've put in the work, you've learned, you've practiced,

143
00:07:19.759 --> 00:07:23.600
<v Speaker 1>and bam, you've found a valid bug. Now what the

144
00:07:23.639 --> 00:07:27.800
<v Speaker 1>book calls report writing and art? Why is the report

145
00:07:27.800 --> 00:07:29.000
<v Speaker 1>itself so important?

146
00:07:29.279 --> 00:07:34.000
<v Speaker 2>Because that report that's your communication channel, it's your your

147
00:07:34.000 --> 00:07:37.439
<v Speaker 2>calling card. Really, a good report gets you noticed how

148
00:07:37.560 --> 00:07:40.879
<v Speaker 2>so well, It leads to faster responses from the security team,

149
00:07:41.199 --> 00:07:43.800
<v Speaker 2>It builds your reputation on the platform, helps you build

150
00:07:43.839 --> 00:07:47.040
<v Speaker 2>relationships with the program owners, and yeah, it often leads

151
00:07:47.040 --> 00:07:49.399
<v Speaker 2>to better payouts. It shows your professional.

152
00:07:49.000 --> 00:07:50.680
<v Speaker 1>So it's not just what you find, but how you

153
00:07:50.720 --> 00:07:51.279
<v Speaker 1>present it.

154
00:07:51.519 --> 00:07:54.680
<v Speaker 2>Absolutely. Yeah, But before you even start writing that report,

155
00:07:55.040 --> 00:07:57.120
<v Speaker 2>there's homework to do on the program itself.

156
00:07:57.240 --> 00:07:59.519
<v Speaker 1>Right, understanding the rules of engagement, What do you need

157
00:07:59.560 --> 00:07:59.759
<v Speaker 1>to know.

158
00:08:00.040 --> 00:08:03.079
<v Speaker 2>You need to read their program policy carefully. What's their mission,

159
00:08:03.519 --> 00:08:07.879
<v Speaker 2>Which specific services or websites are actually in scope, and

160
00:08:08.079 --> 00:08:09.959
<v Speaker 2>just as important, what's out of scope.

161
00:08:10.040 --> 00:08:13.000
<v Speaker 1>Don't want to accidentally test something you shouldn't be touching.

162
00:08:13.040 --> 00:08:15.480
<v Speaker 2>Definitely not that can get you kicked out or worse.

163
00:08:16.560 --> 00:08:19.639
<v Speaker 2>You also need to check their reward structure. They usually

164
00:08:19.639 --> 00:08:25.360
<v Speaker 2>have tables showing bounty ranges for different vulnerability types like critical, high, medium, low.

165
00:08:25.560 --> 00:08:27.279
<v Speaker 1>What else is in the policy.

166
00:08:27.040 --> 00:08:31.720
<v Speaker 2>Eligibility rules like age or location restrictions, connect guidelines, what

167
00:08:31.839 --> 00:08:35.559
<v Speaker 2>not to do like public disclosure before fixing, accessing other

168
00:08:35.679 --> 00:08:41.159
<v Speaker 2>users data, physical attacks, social engineering, the no nos okay,

169
00:08:41.200 --> 00:08:45.000
<v Speaker 2>And often a list of non qualifying vulnerabilities stuff they

170
00:08:45.039 --> 00:08:48.159
<v Speaker 2>already know about or don't consider severe enough, like self

171
00:08:48.159 --> 00:08:52.480
<v Speaker 2>exss sometimes or missing security headers on nonsensitive pages. Knowing

172
00:08:52.519 --> 00:08:53.600
<v Speaker 2>this saves you time.

173
00:08:53.480 --> 00:08:57.399
<v Speaker 1>Good point, save you writing a report they'll just close instantly.

174
00:08:57.039 --> 00:09:00.320
<v Speaker 2>Exactly and finally, look at their commitment to research matures,

175
00:09:00.320 --> 00:09:03.799
<v Speaker 2>how quickly they aim to acknowledge reports, investigate and fix things.

176
00:09:03.960 --> 00:09:07.399
<v Speaker 1>It sets expectations, all right, groundwork done. Now the report itself?

177
00:09:07.480 --> 00:09:09.879
<v Speaker 1>What makes it good? Beyond just the technical details?

178
00:09:09.879 --> 00:09:12.240
<v Speaker 2>Clarity is key. It needs to be easy to follow,

179
00:09:12.360 --> 00:09:16.320
<v Speaker 2>even if the person reading it first isn't deeply technical. Depth. Yes,

180
00:09:16.399 --> 00:09:19.639
<v Speaker 2>focus on the technicals, but avoid bragging or being arrogant,

181
00:09:19.960 --> 00:09:22.799
<v Speaker 2>and be respectful. Always be respectful to the vendor team.

182
00:09:23.120 --> 00:09:26.360
<v Speaker 2>You're trying to build a positive working relationship. It pays

183
00:09:26.399 --> 00:09:27.240
<v Speaker 2>off in the long run.

184
00:09:27.840 --> 00:09:31.639
<v Speaker 1>So what's the structure? The blueprint for a solid report?

185
00:09:32.039 --> 00:09:37.000
<v Speaker 2>Pretty standard format, usually a clear descriptive title, a description

186
00:09:37.120 --> 00:09:39.960
<v Speaker 2>section giving context what the bug is, where you found it.

187
00:09:40.440 --> 00:09:44.519
<v Speaker 2>Then the crucial part, the proof of concept or PAYC,

188
00:09:45.159 --> 00:09:47.600
<v Speaker 2>step by step instructions so they can replicate exactly what

189
00:09:47.679 --> 00:09:51.960
<v Speaker 2>you did. Screenshots, videos highly recommend it visuals make it

190
00:09:52.039 --> 00:09:54.440
<v Speaker 2>so much easier for them to see the issue. After

191
00:09:54.440 --> 00:09:56.240
<v Speaker 2>the PAYC, you need an impact section.

192
00:09:56.600 --> 00:09:58.679
<v Speaker 1>This is where you explain why it matters.

193
00:09:58.360 --> 00:10:03.200
<v Speaker 2>Exactly what are the real world consequences data theft account takeover.

194
00:10:03.480 --> 00:10:06.720
<v Speaker 2>This helps them understand the severity and justifies the bounty

195
00:10:07.120 --> 00:10:08.399
<v Speaker 2>and finally remediation.

196
00:10:09.039 --> 00:10:10.120
<v Speaker 1>Suggesting fixes.

197
00:10:10.279 --> 00:10:13.759
<v Speaker 2>Yeah, offer specific suggestions if you can, maybe point to resources.

198
00:10:13.919 --> 00:10:16.279
<v Speaker 2>Don't just say fix the bug. Show you've thought about

199
00:10:16.279 --> 00:10:17.159
<v Speaker 2>the solution too, and.

200
00:10:17.120 --> 00:10:19.879
<v Speaker 1>What if the team comes back with questions after you submit.

201
00:10:19.799 --> 00:10:23.159
<v Speaker 2>Be prompt, be polite, be thorough with your answers, stick

202
00:10:23.200 --> 00:10:26.080
<v Speaker 2>to the technical facts. The book advice is waiting to

203
00:10:26.120 --> 00:10:28.879
<v Speaker 2>ask about the bounty until after the issue is confirmed

204
00:10:28.960 --> 00:10:29.480
<v Speaker 2>or resolved.

205
00:10:29.600 --> 00:10:31.519
<v Speaker 1>Good tip. And if they reject it.

206
00:10:31.600 --> 00:10:36.039
<v Speaker 2>Accept it gracefully. But if you genuinely believe they've misunderstood

207
00:10:36.080 --> 00:10:40.039
<v Speaker 2>something critical, you can respectfully explain your reasoning again providing

208
00:10:40.039 --> 00:10:42.240
<v Speaker 2>more detail, but don't argue endlessly.

209
00:10:42.879 --> 00:10:45.960
<v Speaker 1>Okay, let's pivot to some of the actual bugs hunters

210
00:10:45.960 --> 00:10:49.480
<v Speaker 1>look for. The book dies into several classics. SEQL injection

211
00:10:49.639 --> 00:10:51.879
<v Speaker 1>or slukewile always seems to be top of the list,

212
00:10:52.000 --> 00:10:55.679
<v Speaker 1>like the oas B Top ten. What's the core idea.

213
00:10:55.320 --> 00:10:58.320
<v Speaker 2>Right, Swile's a big one. Essentially, it's tricking the application

214
00:10:58.360 --> 00:11:01.879
<v Speaker 2>into running malicious sequel code by sneaking it into user

215
00:11:01.879 --> 00:11:04.360
<v Speaker 2>input fields like a search box or a log inform.

216
00:11:05.039 --> 00:11:08.000
<v Speaker 2>It works when the application doesn't properly clean or validate

217
00:11:08.000 --> 00:11:10.480
<v Speaker 2>that input before using it in a database.

218
00:11:10.120 --> 00:11:12.559
<v Speaker 1>Query, and the impact can be huge, oh critical.

219
00:11:12.759 --> 00:11:18.440
<v Speaker 2>You can potentially bypass logins, dump entire user databases, usernames, passwords,

220
00:11:18.440 --> 00:11:21.759
<v Speaker 2>credit card info sometimes or even modify or delete data.

221
00:11:22.120 --> 00:11:23.799
<v Speaker 2>It's really bad news for the company.

222
00:11:23.799 --> 00:11:27.080
<v Speaker 1>If found the book mentions a really interesting uber example

223
00:11:27.679 --> 00:11:29.000
<v Speaker 1>not in a log inform.

224
00:11:28.720 --> 00:11:32.000
<v Speaker 2>Though, Yeah, that was wild. A four thousand dollars bounty

225
00:11:32.039 --> 00:11:35.440
<v Speaker 2>for sequel found by Orange SI in an unsubscribed link

226
00:11:35.480 --> 00:11:37.000
<v Speaker 2>in an advertising email.

227
00:11:36.720 --> 00:11:37.879
<v Speaker 1>And unsubscribed links.

228
00:11:37.919 --> 00:11:42.320
<v Speaker 2>Seriously, seriously, he found a time based blind sequel. He

229
00:11:42.399 --> 00:11:46.080
<v Speaker 2>injected a command like sleep into a parameter in the link.

230
00:11:46.399 --> 00:11:48.399
<v Speaker 2>User read. I think it was if the page took

231
00:11:48.399 --> 00:11:51.279
<v Speaker 2>twelve seconds longer to load. He knew the database executed

232
00:11:51.320 --> 00:11:53.840
<v Speaker 2>his command. He used that to figure out datase names

233
00:11:53.840 --> 00:11:54.399
<v Speaker 2>and users.

234
00:11:54.480 --> 00:11:55.960
<v Speaker 1>Wow, what's the lesson there?

235
00:11:56.240 --> 00:11:59.159
<v Speaker 2>The critical bugs can lurk in the most unexpected places.

236
00:11:59.240 --> 00:12:02.559
<v Speaker 2>Don't just test the obvious login forms. Test everything, even

237
00:12:02.600 --> 00:12:05.240
<v Speaker 2>email links, background processes, everywhere.

238
00:12:05.320 --> 00:12:08.639
<v Speaker 1>Incredible. Okay, so segle hits the database. What about attacks

239
00:12:08.639 --> 00:12:11.519
<v Speaker 1>that target the user's logged in session that brings us

240
00:12:11.559 --> 00:12:13.879
<v Speaker 1>to CSRF Cross Site Request forgery right?

241
00:12:14.000 --> 00:12:17.360
<v Speaker 2>CSRS is sneaky. It basically tricks a logged in user's

242
00:12:17.399 --> 00:12:20.039
<v Speaker 2>browser into making a request to a website they trust,

243
00:12:20.279 --> 00:12:23.120
<v Speaker 2>but the request actually performs an action the attacker wants,

244
00:12:23.200 --> 00:12:23.799
<v Speaker 2>not the user.

245
00:12:23.879 --> 00:12:24.879
<v Speaker 1>How does it even work?

246
00:12:25.159 --> 00:12:29.000
<v Speaker 2>It abuses the trust relationship your browser stores session cookies

247
00:12:29.039 --> 00:12:32.480
<v Speaker 2>for sites you're logged into. If you visit a malicious site,

248
00:12:32.559 --> 00:12:35.679
<v Speaker 2>it might contain hidden code, maybe an image tag with

249
00:12:35.720 --> 00:12:39.080
<v Speaker 2>a weird URL, or a hidden form that submits automatically

250
00:12:39.080 --> 00:12:42.639
<v Speaker 2>that sends a request to say, your bank site using

251
00:12:42.679 --> 00:12:44.559
<v Speaker 2>your existing session cookie.

252
00:12:44.200 --> 00:12:46.679
<v Speaker 1>So the bank thinks you made the request exactly.

253
00:12:46.879 --> 00:12:49.639
<v Speaker 2>It could be used to transfer funds, change your email address,

254
00:12:49.679 --> 00:12:52.279
<v Speaker 2>to delete your account, anything you can normally do wle

255
00:12:52.279 --> 00:12:55.200
<v Speaker 2>logged in. The classic example used to be like clicking

256
00:12:55.240 --> 00:12:57.440
<v Speaker 2>a link on a forum that secretly makes your Facebook

257
00:12:57.440 --> 00:12:59.840
<v Speaker 2>profile post spam nasty stuff.

258
00:13:00.039 --> 00:13:02.279
<v Speaker 1>How do attackers usually deliver the payload?

259
00:13:02.679 --> 00:13:06.320
<v Speaker 2>Common ways are get CSRF, maybe hiding the malicious URL

260
00:13:06.360 --> 00:13:11.039
<v Speaker 2>in an MG tag, or POSTDSRF using a hidden HTML

261
00:13:11.120 --> 00:13:14.720
<v Speaker 2>form with JavaScript dismitted automatically when you load the page.

262
00:13:14.799 --> 00:13:16.960
<v Speaker 1>And the book had a serious example from Badu.

263
00:13:17.200 --> 00:13:19.879
<v Speaker 2>Yeah, that was a critical one. Full account takeover was

264
00:13:19.919 --> 00:13:23.519
<v Speaker 2>possible by exploiting a CSRF vulnerability to add a recovery

265
00:13:23.519 --> 00:13:26.519
<v Speaker 2>email address to the victim's account. The twist was how

266
00:13:26.559 --> 00:13:28.480
<v Speaker 2>they bypassed the usual protection.

267
00:13:28.240 --> 00:13:30.320
<v Speaker 1>The anti CSRF token right.

268
00:13:30.799 --> 00:13:34.919
<v Speaker 2>Usually forms include a unique hidden token to prevent CSRF,

269
00:13:35.480 --> 00:13:38.080
<v Speaker 2>but in this Bidue case, the researcher found the token

270
00:13:38.159 --> 00:13:41.679
<v Speaker 2>wasn't properly protected. It was actually accessible within a separate

271
00:13:41.759 --> 00:13:44.720
<v Speaker 2>JavaScript file, so they could grab the token and then

272
00:13:44.799 --> 00:13:46.159
<v Speaker 2>forge their request. Choose.

273
00:13:46.200 --> 00:13:49.480
<v Speaker 1>You need to protect those tokens properly too, okay. Next up,

274
00:13:49.759 --> 00:13:54.039
<v Speaker 1>Cross site scripting XSS, another perennial favorite on the OAS

275
00:13:54.200 --> 00:13:55.039
<v Speaker 1>Top ten YEP.

276
00:13:55.200 --> 00:13:58.519
<v Speaker 2>XSS is everywhere. It's another input validation failure, but this

277
00:13:58.679 --> 00:14:02.320
<v Speaker 2>time the attacker in ject's malicious JavaScript or other client

278
00:14:02.399 --> 00:14:05.759
<v Speaker 2>side script into a web page, which then gets executed

279
00:14:05.759 --> 00:14:07.600
<v Speaker 2>in the browser of other users who view.

280
00:14:07.480 --> 00:14:10.600
<v Speaker 1>That page, so it attacks the user directly via their browser.

281
00:14:10.720 --> 00:14:14.120
<v Speaker 2>Pretty much. It often requires some user interaction, like clicking

282
00:14:14.120 --> 00:14:16.159
<v Speaker 2>a link or just loading a compromised page.

283
00:14:16.360 --> 00:14:18.360
<v Speaker 1>What are the main flavors of XSS?

284
00:14:18.519 --> 00:14:21.519
<v Speaker 2>The book outlines the main three. You've got reflected XSS,

285
00:14:21.639 --> 00:14:24.080
<v Speaker 2>which is kind of immediate. The malicious script is in

286
00:14:24.120 --> 00:14:26.960
<v Speaker 2>the URL or input, the server reflects it back, and

287
00:14:27.039 --> 00:14:29.399
<v Speaker 2>it runs in the user's browser right then, like a

288
00:14:29.440 --> 00:14:32.559
<v Speaker 2>malicious link in an email, affects only the person who.

289
00:14:32.399 --> 00:14:34.320
<v Speaker 1>Clicks okay, one off. What else?

290
00:14:34.480 --> 00:14:38.120
<v Speaker 2>Then there's stored XSS, which is often more dangerous. The

291
00:14:38.120 --> 00:14:41.279
<v Speaker 2>malicious script gets permanently saved on the server, maybe in

292
00:14:41.320 --> 00:14:44.840
<v Speaker 2>a comment thread, a user profile, a product.

293
00:14:44.519 --> 00:14:47.080
<v Speaker 1>Review, so anyone who views that page gets.

294
00:14:46.879 --> 00:14:51.000
<v Speaker 2>Hit potentially yes. Every time that infected data is displayed,

295
00:14:51.120 --> 00:14:55.320
<v Speaker 2>the script runs. The book mentions a funny sort of example,

296
00:14:55.879 --> 00:14:59.600
<v Speaker 2>a QA tester entering scripteller script into a field crashes

297
00:14:59.639 --> 00:15:02.879
<v Speaker 2>a market app with pop ups later that stored XSS

298
00:15:02.960 --> 00:15:06.480
<v Speaker 2>and the third type DOM based EXSS. This one's tricky

299
00:15:06.519 --> 00:15:09.440
<v Speaker 2>because the vulnerability exists entirely in the client side code,

300
00:15:09.519 --> 00:15:12.720
<v Speaker 2>in the browser's document object model DOM. The server might

301
00:15:12.720 --> 00:15:14.879
<v Speaker 2>not even see the malicious script, but the JavaScript on

302
00:15:14.879 --> 00:15:18.159
<v Speaker 2>the page takes input, maybe from the ural fragment like hashtag,

303
00:15:18.440 --> 00:15:20.720
<v Speaker 2>and handles it insecurely, allowing the script to.

304
00:15:20.759 --> 00:15:23.559
<v Speaker 1>Run right, And the book mentions a massive ten thousand

305
00:15:23.600 --> 00:15:26.840
<v Speaker 1>dollars payout for a Yahoo Mail stored XSS. What was

306
00:15:26.840 --> 00:15:27.480
<v Speaker 1>special there?

307
00:15:27.600 --> 00:15:29.919
<v Speaker 2>That was a really clever one. In the Yahoo Mail editor,

308
00:15:30.080 --> 00:15:33.240
<v Speaker 2>when you attached a file, it generated some htmil automatically,

309
00:15:33.320 --> 00:15:38.039
<v Speaker 2>a parameter within that HTML data EARL wasn't properly sanitized. Yeah,

310
00:15:38.480 --> 00:15:41.360
<v Speaker 2>by crafting a special email fragment, an attacker could inject

311
00:15:41.440 --> 00:15:44.919
<v Speaker 2>JavaScript into that data EARL and would execute for anyone

312
00:15:45.039 --> 00:15:48.320
<v Speaker 2>viewing the email high impact because it's in the mail client.

313
00:15:48.799 --> 00:15:52.679
<v Speaker 2>Great explanation in the report Big Bounty showed how complex

314
00:15:52.720 --> 00:15:54.720
<v Speaker 2>interactions can hide EXSS.

315
00:15:55.320 --> 00:15:59.320
<v Speaker 1>Okay, moving beyond these more classic vulnerability types, the book

316
00:15:59.360 --> 00:16:03.600
<v Speaker 1>talks about app implication logic vulnerabilities. These sound different, they

317
00:16:03.639 --> 00:16:04.080
<v Speaker 1>really are.

318
00:16:04.440 --> 00:16:07.679
<v Speaker 2>Unlike SQL or XSS, where you're often looking for specific

319
00:16:07.720 --> 00:16:11.679
<v Speaker 2>code patterns or lack of sanitization, logic flaws are about

320
00:16:11.679 --> 00:16:15.159
<v Speaker 2>breaking the intended process or rules of the application. How So,

321
00:16:15.639 --> 00:16:18.480
<v Speaker 2>developers build an application with a certain workflow in mind,

322
00:16:18.679 --> 00:16:22.120
<v Speaker 2>a specific paradigm, as the book calls it. Logic flaws

323
00:16:22.120 --> 00:16:24.679
<v Speaker 2>happen when a user does something unexpected that the developer

324
00:16:24.720 --> 00:16:29.840
<v Speaker 2>didn't anticipate bypassing controls or achieving an unintended outcome. Automated

325
00:16:29.840 --> 00:16:32.120
<v Speaker 2>scanners usually miss these completely.

326
00:16:31.840 --> 00:16:34.039
<v Speaker 1>Because they're not looking for does this make sense? They're

327
00:16:34.080 --> 00:16:37.120
<v Speaker 1>looking for does this match a known bad pattern?

328
00:16:37.279 --> 00:16:41.480
<v Speaker 2>Exactly? Finding logic flaws requires you to really understand the

329
00:16:41.559 --> 00:16:45.320
<v Speaker 2>business logic, the user journey. You map out how things

330
00:16:45.360 --> 00:16:48.759
<v Speaker 2>should work and then try to subvert it. Look at forms,

331
00:16:49.120 --> 00:16:54.039
<v Speaker 2>API calls, processes involving email or SMS, anywhere state changes

332
00:16:54.120 --> 00:16:55.039
<v Speaker 2>or assumptions are made.

333
00:16:55.080 --> 00:16:58.120
<v Speaker 1>Can you give an example. The Starbucks one sounded intriguing.

334
00:16:58.399 --> 00:17:00.720
<v Speaker 2>That was a great example of thinking out side the box.

335
00:17:01.159 --> 00:17:05.279
<v Speaker 2>A race condition the hunter bought multiple gift cards, initiated

336
00:17:05.279 --> 00:17:08.319
<v Speaker 2>transfers between them, but then use command line tools like

337
00:17:08.359 --> 00:17:11.480
<v Speaker 2>CURL to send simultaneous request really fast.

338
00:17:11.599 --> 00:17:12.279
<v Speaker 1>What did that do?

339
00:17:12.559 --> 00:17:16.160
<v Speaker 2>It basically confused the applications process for finalizing the transfer

340
00:17:16.160 --> 00:17:19.440
<v Speaker 2>and updating balances. By hitting it rapidly, they prevented the

341
00:17:19.440 --> 00:17:22.920
<v Speaker 2>session from clearing correctly, effectively tricking the system into giving

342
00:17:22.920 --> 00:17:25.640
<v Speaker 2>them free credit before the balance is properly updated.

343
00:17:25.680 --> 00:17:28.039
<v Speaker 1>Because the developer assumed someone would just use a slow

344
00:17:28.240 --> 00:17:30.240
<v Speaker 1>human operated browser.

345
00:17:29.839 --> 00:17:33.559
<v Speaker 2>Percisely, they didn't account for programmatic high speed interaction by

346
00:17:33.640 --> 00:17:37.519
<v Speaker 2>passing the expected sequence of operations. Logitflaws often exploit these

347
00:17:37.599 --> 00:17:38.400
<v Speaker 2>kinds of assumptions.

348
00:17:38.720 --> 00:17:42.599
<v Speaker 1>Very clever. What about subdomain takeovers sounds like digital squatting?

349
00:17:42.920 --> 00:17:45.920
<v Speaker 2>It kind of is. It's a configuration mistake. Imagine a

350
00:17:45.960 --> 00:17:49.079
<v Speaker 2>company sets up a subdomain like blog, dot company, dot

351
00:17:49.079 --> 00:17:53.079
<v Speaker 2>com and points its DNS record maybe a CNAM record

352
00:17:53.359 --> 00:17:57.160
<v Speaker 2>to a third party service like Heroku or GitHub pages. Okay,

353
00:17:57.400 --> 00:18:00.000
<v Speaker 2>now what if they stop using that service or delete

354
00:18:00.079 --> 00:18:02.759
<v Speaker 2>their account there? But forget to remove the DNS record.

355
00:18:02.839 --> 00:18:05.119
<v Speaker 1>Ah, so the CNA man still points to a service,

356
00:18:05.160 --> 00:18:06.960
<v Speaker 1>but it's now unclaimed exactly.

357
00:18:07.200 --> 00:18:09.480
<v Speaker 2>An attacker can then go to that third party service,

358
00:18:09.640 --> 00:18:12.839
<v Speaker 2>claim that specific host name blog dot company, dot com,

359
00:18:13.119 --> 00:18:15.680
<v Speaker 2>and suddenly they control the content served on that official

360
00:18:15.720 --> 00:18:16.559
<v Speaker 2>looking subdomain.

361
00:18:16.640 --> 00:18:18.519
<v Speaker 1>Oof. What's the danger there?

362
00:18:18.680 --> 00:18:21.880
<v Speaker 2>It's critical they get host phishing pages, steal session cookies

363
00:18:21.920 --> 00:18:25.039
<v Speaker 2>for the main domain if cookies are scoped improperly bypass

364
00:18:25.119 --> 00:18:29.160
<v Speaker 2>security policies like CSP, intercept emails if it's an MX record,

365
00:18:29.160 --> 00:18:32.839
<v Speaker 2>takeover loads of bad stuff. Uber and Starbucks both had

366
00:18:32.839 --> 00:18:37.400
<v Speaker 2>instances mentioned where subdomains pointed to unclaimed cloud resources, easy

367
00:18:37.440 --> 00:18:39.200
<v Speaker 2>points for attackers if not monitored.

368
00:18:39.240 --> 00:18:41.720
<v Speaker 1>A reminder to clean up your digital loose ends. Okay.

369
00:18:41.799 --> 00:18:46.640
<v Speaker 1>Next vulnerability xxse XML external entity XML feels a bit

370
00:18:46.640 --> 00:18:47.759
<v Speaker 1>old school. Is this still a thing?

371
00:18:47.960 --> 00:18:51.480
<v Speaker 2>Oh? Definitely, Lots of systems still process XML, especially in

372
00:18:51.519 --> 00:18:54.799
<v Speaker 2>back end integrations or file uploads. Xx happens when an

373
00:18:54.799 --> 00:18:58.640
<v Speaker 2>application parses XML input from a user, and that XML

374
00:18:58.720 --> 00:19:01.839
<v Speaker 2>contains references to extraternal resources external.

375
00:19:01.599 --> 00:19:03.839
<v Speaker 1>Entities, and the parser just fetches them.

376
00:19:03.960 --> 00:19:07.279
<v Speaker 2>If it's poorly configured, Yes, an attacker my craft XML

377
00:19:07.480 --> 00:19:11.000
<v Speaker 2>like in its oofs system file dot it's CP PASSWD

378
00:19:11.200 --> 00:19:13.720
<v Speaker 2>and then a reference and oaths later. If the parser

379
00:19:13.720 --> 00:19:17.079
<v Speaker 2>allows external entities, it might actually read these ecopasswood file

380
00:19:17.119 --> 00:19:19.599
<v Speaker 2>from the server and include its contents in the response.

381
00:19:19.799 --> 00:19:21.640
<v Speaker 1>Yikes, so it can read local files.

382
00:19:21.720 --> 00:19:24.240
<v Speaker 2>It can read local files, make network requests from the

383
00:19:24.240 --> 00:19:27.440
<v Speaker 2>server's perspective, acting like a proxy, or even cause denial

384
00:19:27.480 --> 00:19:30.519
<v Speaker 2>of service by making the parser consume huge amounts of resources.

385
00:19:30.680 --> 00:19:32.279
<v Speaker 2>A billion lass attack.

386
00:19:32.119 --> 00:19:34.680
<v Speaker 1>What's a Surprising place XXC has shown up.

387
00:19:34.759 --> 00:19:38.079
<v Speaker 2>The book mentions a Facebook case involving a dot docks file.

388
00:19:37.920 --> 00:19:40.720
<v Speaker 1>Upload a word document, how is that XML?

389
00:19:41.079 --> 00:19:45.240
<v Speaker 2>Modern office documents dot dox, dot xlsx, et cetera are

390
00:19:45.279 --> 00:19:50.039
<v Speaker 2>actually zip archives containing multiple XML files. By embedding a

391
00:19:50.039 --> 00:19:55.440
<v Speaker 2>malicious DTD document type definition referencing an external entity within

392
00:19:55.519 --> 00:19:58.440
<v Speaker 2>one of those XML files inside the dot dos, an

393
00:19:58.480 --> 00:20:03.039
<v Speaker 2>attacker could trigger xx E when Facebook process the uploaded document.

394
00:20:03.720 --> 00:20:06.680
<v Speaker 2>Show that even seemingly benign file uploads can be vectors.

395
00:20:06.920 --> 00:20:10.720
<v Speaker 1>Wow. Okay. Last one in the section template injection, specifically

396
00:20:10.759 --> 00:20:15.440
<v Speaker 1>server side template injection SSTI. Sounds complex, It can be, and.

397
00:20:15.400 --> 00:20:18.559
<v Speaker 2>The impact is often severe. Many web frameworks use template

398
00:20:18.559 --> 00:20:22.559
<v Speaker 2>engines like GINGA two, Python free marker Java twig php

399
00:20:23.079 --> 00:20:27.880
<v Speaker 2>to dynamically generate HTML pages by embedding data into templates.

400
00:20:27.519 --> 00:20:29.480
<v Speaker 1>Right like inserting the username into welcome.

401
00:20:29.599 --> 00:20:32.559
<v Speaker 2>Yeah, exactly, the sesdi happens when user supplied input gets

402
00:20:32.559 --> 00:20:36.279
<v Speaker 2>embedded directly into the template itself without proper sanitization, rather

403
00:20:36.400 --> 00:20:38.480
<v Speaker 2>than just being treated as data within the template.

404
00:20:38.519 --> 00:20:39.160
<v Speaker 1>What's the difference?

405
00:20:39.240 --> 00:20:40.880
<v Speaker 2>If the user input is treated as part of the

406
00:20:40.920 --> 00:20:44.160
<v Speaker 2>template code, the template engine might execute it, so instead

407
00:20:44.160 --> 00:20:47.000
<v Speaker 2>of just displaying the user's input, it interprets commands within it,

408
00:20:47.119 --> 00:20:50.799
<v Speaker 2>leading to best case maybe cross site scripting, worst case

409
00:20:51.039 --> 00:20:55.079
<v Speaker 2>full remote code execution RCE on the server. Because template

410
00:20:55.079 --> 00:20:58.000
<v Speaker 2>engines often have access to powerful back end objects and.

411
00:20:58.039 --> 00:21:00.079
<v Speaker 1>Functions, how would you even spot that.

412
00:21:00.119 --> 00:21:03.160
<v Speaker 2>You try injecting characters or sequences that the template engine

413
00:21:03.240 --> 00:21:05.960
<v Speaker 2>uses for its syntax. A common test payload is something

414
00:21:06.039 --> 00:21:08.559
<v Speaker 2>like if the application responds with forty nine instead of

415
00:21:08.599 --> 00:21:11.599
<v Speaker 2>just echoing, you know, the template engine evaluated it.

416
00:21:11.680 --> 00:21:13.759
<v Speaker 1>And the book had an Uber example for this too.

417
00:21:13.839 --> 00:21:17.920
<v Speaker 2>Yeah, jingitwo ssti uh hunter put seven foot seven, which

418
00:21:17.920 --> 00:21:20.720
<v Speaker 2>in Python jingitw repeats the string seven seven seven seven

419
00:21:20.759 --> 00:21:24.440
<v Speaker 2>times into a name field on writer dot uber dot com.

420
00:21:25.000 --> 00:21:27.319
<v Speaker 2>An email sent by the system then contained seven seven

421
00:21:27.359 --> 00:21:30.359
<v Speaker 2>seven seven seven seven seven in the body, confirming the

422
00:21:30.359 --> 00:21:33.440
<v Speaker 2>injection and evaluation. That opened the door to extracting more

423
00:21:33.440 --> 00:21:34.680
<v Speaker 2>info from the server environment.

424
00:21:34.960 --> 00:21:38.079
<v Speaker 1>Fascinating stuff. Okay, we've covered a lot of ground on vulnerabilities.

425
00:21:38.359 --> 00:21:40.559
<v Speaker 1>What about the tools of the trade. What's in a

426
00:21:40.559 --> 00:21:42.359
<v Speaker 1>bug bounty Hunter's digital.

427
00:21:42.039 --> 00:21:46.359
<v Speaker 2>Backpack tools are definitely crucial assistance. You absolutely need an

428
00:21:46.480 --> 00:21:50.119
<v Speaker 2>HTTP proxy. BURP Suite is kind of the industry standard.

429
00:21:50.119 --> 00:21:53.680
<v Speaker 2>It lets you intercept, inspect, and modify all the traffic

430
00:21:53.960 --> 00:21:58.720
<v Speaker 2>between your browser and the target application. Zap Ze Attack

431
00:21:58.799 --> 00:22:02.480
<v Speaker 2>Proxy from OAS is a great free alternative.

432
00:22:01.960 --> 00:22:04.680
<v Speaker 1>So you can see exactly what's being sent and received precisely.

433
00:22:05.039 --> 00:22:08.240
<v Speaker 2>Then maybe network analyzers like wire Shark for looking at

434
00:22:08.319 --> 00:22:11.319
<v Speaker 2>raw network packets, especially if non standard ports are involved.

435
00:22:11.880 --> 00:22:14.480
<v Speaker 2>For scanning, you've got things like squall map, which is

436
00:22:14.519 --> 00:22:17.720
<v Speaker 2>amazing for automating SQL injection, detection and exploitation.

437
00:22:17.920 --> 00:22:20.119
<v Speaker 1>What about finding targets or mapping them out?

438
00:22:20.440 --> 00:22:23.240
<v Speaker 2>End map is essential for ports scanning and service discovery.

439
00:22:23.759 --> 00:22:26.559
<v Speaker 2>For broader reconnaissance, Showdian is like a search engine for

440
00:22:26.720 --> 00:22:31.279
<v Speaker 2>Internet connected devices. Tools like reconning help automate finding subdomains

441
00:22:31.279 --> 00:22:35.559
<v Speaker 2>and related infrastructure and simple browser extensions for managing proxies

442
00:22:35.640 --> 00:22:37.000
<v Speaker 2>or cookies are super helpful to.

443
00:22:37.160 --> 00:22:40.640
<v Speaker 1>It's quite the arsenal. But tools alone aren't enough right

444
00:22:40.960 --> 00:22:44.680
<v Speaker 1>this field change is so fast? How important is continuous learning?

445
00:22:44.880 --> 00:22:47.640
<v Speaker 2>It's absolutely paramount. You cannot rest on what you knew

446
00:22:47.680 --> 00:22:49.119
<v Speaker 2>last year or even last month.

447
00:22:49.000 --> 00:22:51.000
<v Speaker 1>Sometimes, so how do people stay sharp?

448
00:22:51.240 --> 00:22:55.240
<v Speaker 2>Manyways? Formal training and certifications can be valuable. The book

449
00:22:55.279 --> 00:22:59.720
<v Speaker 2>mentions gisserts like GPN or dwopped for web apps and

450
00:23:00.079 --> 00:23:04.200
<v Speaker 2>Ends of Securities OSCP or OSWA are highly respected for

451
00:23:04.240 --> 00:23:05.440
<v Speaker 2>their practical, hands on.

452
00:23:05.440 --> 00:23:07.319
<v Speaker 1>Approach beyond formal searts.

453
00:23:07.119 --> 00:23:10.880
<v Speaker 2>Reading always reading classic books like The Web Application Hacker's

454
00:23:10.960 --> 00:23:15.559
<v Speaker 2>Handbook are foundational. Engaging and capture the flag CTF competitions

455
00:23:15.839 --> 00:23:19.200
<v Speaker 2>and playing on vulnerable practice platforms like Hack the Box

456
00:23:19.319 --> 00:23:24.039
<v Speaker 2>or DVWA. Damn Vulnerable Web Application is amazing hands.

457
00:23:23.720 --> 00:23:26.200
<v Speaker 1>On practice learning by doing essentially exactly.

458
00:23:26.400 --> 00:23:29.400
<v Speaker 2>Plus follow blogs. Port Twigger, the makers of Burp, has

459
00:23:29.440 --> 00:23:32.880
<v Speaker 2>a great one. Watch YouTube channels dedicated to hacking and security,

460
00:23:33.240 --> 00:23:36.039
<v Speaker 2>and participate in the community. Go to conferences like Defcon

461
00:23:36.200 --> 00:23:39.680
<v Speaker 2>or black Hat. If you can join local OSS chapter meetings,

462
00:23:39.839 --> 00:23:42.440
<v Speaker 2>connect online. It's an ecosystem you need to be part of.

463
00:23:42.599 --> 00:23:45.039
<v Speaker 1>That makes total sense. It's a journey, not a destination.

464
00:23:45.279 --> 00:23:45.799
<v Speaker 2>Definitely.

465
00:23:46.039 --> 00:23:48.440
<v Speaker 1>Well, we have certainly covered a lot today. We've journeyed

466
00:23:48.440 --> 00:23:50.759
<v Speaker 1>through the world of bug bounty hunting, figuring out what

467
00:23:50.880 --> 00:23:53.799
<v Speaker 1>it is, the platforms like hacker one and bug crowd,

468
00:23:54.119 --> 00:23:57.720
<v Speaker 1>why reputation metrics like signal and impact matter, yeah, and the.

469
00:23:57.680 --> 00:24:02.160
<v Speaker 2>Path to getting started, emphasizing learn and practice over formal SERTs,

470
00:24:02.519 --> 00:24:05.960
<v Speaker 2>the importance of starting small and that crucial mindset.

471
00:24:06.119 --> 00:24:08.279
<v Speaker 1>Then we dug into the art of the report, why

472
00:24:08.319 --> 00:24:11.200
<v Speaker 1>clarity and proof of concept are so vital, and of

473
00:24:11.200 --> 00:24:13.200
<v Speaker 1>course the vulnerabilities themselves.

474
00:24:12.799 --> 00:24:17.680
<v Speaker 2>SIEGWI in surprising places like unsubscribed links CSRF bypassing tokens

475
00:24:17.720 --> 00:24:21.160
<v Speaker 2>hidden in JS files, the different flavors of XSS and

476
00:24:21.200 --> 00:24:22.440
<v Speaker 2>that big Yahoo.

477
00:24:22.200 --> 00:24:25.559
<v Speaker 1>Male payout, the cleverness needed for logic flaws like that

478
00:24:25.599 --> 00:24:30.279
<v Speaker 1>Starbucks race condition, the risks of forgetting dns with subdomain takeovers,

479
00:24:30.559 --> 00:24:33.359
<v Speaker 1>finding xxx and word docs, and the power of server

480
00:24:33.440 --> 00:24:34.799
<v Speaker 1>side template injection.

481
00:24:34.599 --> 00:24:37.000
<v Speaker 2>Plus the tools like Burke Suite and school Map, and

482
00:24:37.039 --> 00:24:41.240
<v Speaker 2>the absolute necessity of continuous learning through books CTFs in

483
00:24:41.319 --> 00:24:41.960
<v Speaker 2>the community.

484
00:24:42.039 --> 00:24:44.960
<v Speaker 1>It really paints a picture of a hidden digital landscape,

485
00:24:45.000 --> 00:24:48.440
<v Speaker 1>doesn't It where tiny oversights can cascade into major problems,

486
00:24:48.720 --> 00:24:52.119
<v Speaker 1>but also where sharp eyes and ethical reporting are genuinely rewarded.

487
00:24:52.200 --> 00:24:54.400
<v Speaker 2>It's a constant cat and mouse game, and these hunters

488
00:24:54.440 --> 00:24:55.319
<v Speaker 2>are on the front lines.

489
00:24:55.599 --> 00:24:58.440
<v Speaker 1>So a final thought for everyone listening. As you go

490
00:24:58.519 --> 00:25:02.279
<v Speaker 1>about your day using app, browsing websites, think about those

491
00:25:02.319 --> 00:25:05.839
<v Speaker 1>hidden paths. What assumptions are being made, what processes could

492
00:25:05.880 --> 00:25:09.640
<v Speaker 1>be subverted? How might knowing about these potential vulnerabilities change

493
00:25:09.680 --> 00:25:11.880
<v Speaker 1>how you interact with technology every single day.