- We can actually find
the user's password here in plain text. This is basically a beginners guide to all the vulnerabilities
that are most common in web applications. - It's like trying to find the needle in the haystack type of
thing, is that right? - Experience the thrill of
being a hacker and a bug hunter. - Wow! Great reflexes. (upbeat music) - Hey everyone, David Bombal back with
a very special guest. Vickie, welcome. - Hi everyone, thanks for having me on your show David. - If you don't know who Vickie is, she's the author of this book, Bug Bounty Bootcamp. Fantastic book if you want
to get started in bug bounty. Vickie, I really love what
you did with this book. You are starting for instance, talking about Bug Bounties, but you also like talk about the basics of how the web works, you talk about web
vulnerabilities and so forth and we're gonna talk about one of those, just for everyone who's watching. We're gonna do a demo of IDOR. If you only interested
in looking at the demo, then jump to this timestamp
where Vickie demonstrates that. Vickie, tell me why did
you write this book? - So just for a little bit of background, for people who don't know
what the book is about, Bug Bounty Bootcamp is
a book that teaches you how to hack web applications. - Is it for beginners, is that right? - I wrote it to prepare people
with little to no experience in Bug Bounties to start participate in Bug Bounty programs. It's aimed at setting you up for success. So you will learn things like
how to perform reconnaissance on a target, how to identify vulnerabilities, and then how to exploit them. So that part I find is useful for a lot of more advanced hackers as well, since even though you've
been hacking for a while, you might not be familiar with all of the techniques
presented in the book, but I did write it with
the beginner in mind. And even if you have no experience in Bug Bounty's web
security or programming, you can still use the book and you can still follow
along pretty well. - I'm assuming you took a lot
of the stuff that you learned over the years and then
you put it into a book. - It's really a deep dive into
what I learned over the years as a bug hunter. I didn't really start writing the content of Bug Bounty Boot Camp
wanting to publish a book. I started writing content
about web security and Bug Bounty on my blog
first a few years ago, because I was, you know, trying to get into cyber
security and Bug Bounties alone. You know, just sitting in front of
my laptop all day hunting on different targets by myself, I got really lonely and I
started to lose motivation. I wanted to connect more with people who have the same interests, and who also love to do bug bounties. So I started my blog
to connect with people, and then over time I found
that the contents on my blog as well as a lot of the
notes that I was accumulating over the years from my own learning, I wanted to publish that so
that I can help beginners get into bug bounties as well. - Yeah, I think it happens with some, with various authors that I've interviewed where they writing
content to help themselves and also connect with the community, and then that gets turned into a book. Hey everyone, it's David Bumble back
with a very special guest. He's the author of this book, of this book. Fantastic, fantastic book. Why did you decide to write this? - I thought, yeah sure, okay, I can find some tutorials online but didn't really find anything. - And I switched over
into application security. I was really, really excited to join and there was no book that
would kind of teach me. - And then I started taking notes, and I got to about 150 pages of notes, when I thought it through
and decided, you know what, this is halfway to being
a book, so why not? - What is Bug Bounty? Which company do you recommend, if any? Let's start with like the beginner stuff and then we'll get into
the more ticky stuff. - So Bug Bounty programs are a way for companies to pay researchers and pay hackers to find vulnerabilities on their applications and
then reward them monetarily or in turn of reputation
for their findings, right? So it's really like a win-win
situation for the company as well as the hackers. Bug Bounty is sort of like a method for companies to catch a
security vulnerabilities that somehow end up escaping their in-house security capabilities. Let's say that you are a company, you've already had some
security engineers working on your products and you
already have staff analysis, code scanning going on, but there's always those
vulnerabilities that somehow, slip outta your hands, right? Or there sometimes are novel
vulnerabilities that tools and engineers just don't know about yet before the researcher reveals it to them. And so companies have an
opportunity to find out about these vulnerabilities
and then the hackers on the other hand can
do what they love like, which is hunting on applications. Look for vulnerabilities, experience the thrill of being
a hacker and a bug hunter. - Wow! Great reflexes. - And get rewarded monetarily as well. I really love Bug Bounty programs because it helped me learn
a lot about web hacking and web application security in general. I think it's a really good place for beginners to get started in the field. It's one of those niche fields
that have a lower barrier of entry. So I really recommend
people who want to get into info side, well who want to sort of pivot into either penetration testing, into application security
to give Bug Bounty a try. - You can do it part-time, right? - Yes. I think most bug bounty hunters
probably started off doing it part-time, because it's one of those
really flexible gigs, right? You just hunt on a program or
a company when you have time, and so you get rewarded
for your findings instead of the hours worked. - People who want to get into a field, the problem is how do you get
experience without experience? Companies always want experience and then, like how do you get experience
if they don't give you a job? And this is a nice way to do that. - Yeah, that's for sure. I think my experience with Bug Bounty, was kind of like that actually. So I started Bug Bounties
when I was in college, and I was a student in computer science. I had no experience in application
security or web security and with Bug Bounties
I found a way to learn, slowly learn about the field, but while also gaining these
like resume points, right? While I do it. So I got really lucky in Bug Bounties and that I experienced very early success. I think I pretty much found a bounty on my first night of hunting. It was a really low severity report and I didn't find bugs, for like I think six
months or so after that. But it was enough to keep me going, right? Because that was such an
amazing experience to be able to earn money as a student while I also learn about the cybersecurity field. - I love what you did there. You didn't wait till you, like we're in the workforce, you were gaining experience
while you're still in college, and I think that's fantastic. You're gaining real world experience and that's what's different to CTS, right? Because you're working on real companies. - Yeah, that's for sure. It's really motivating
to, to know that you, you can contribute to the industry or to the security of these big companies or these websites while
you're still a student and while you don't have a
full time or even part-time job in cyber security. Starting early as a
student in Bug Bounties, really enabled me to start
finding jobs in cyber security after I graduated university as well. - You got it. You got real world experience, like proper real world experience, not just simulations. Real world experience which
enabled you to, you know, it allowed doors to open
because you had the experience while you were still studying. So I love that, but I have to come back to the question, which Bug Bounty programs exist and which one would you
recommend for a beginner? I recommend first reading
about these vulnerabilities, either via my book or some
other web security book, to get familiar with
how web technology works and how these vulnerabilities works and then practice some
hacking techniques like IDOR or Cross-Site Scripting
on an online lab first. So a good one is PortSwigger Academy, is a really good training
ground for learning how to use, some of the basic exploitation techniques. The examples on PortSwigger
are really simple, and a lot of the times they
don't really represent, what you actually see in
websites because a lot of the complexities of
real world vulnerabilities or applications are simplified for you. But nevertheless, it's a really good way to
learn about the mechanics of what you're doing there. And then once you get very familiar with how these vulnerabilities work, I recommend going on some VDP's. So Vulnerability Disclosure Programs, just to try out hunting, right? If you search on hacker one, if you search on bug crowd or integrity, there are a lot of public
programs that don't pay money and you can usually
filter for these programs by searching for things like
vulnerability disclosure, on background it's called Kudos only, and on integrity, I think it's called
Responsible Disclosure. These programs because they don't pay, they're not as competitive
as the paid programs. I think I got really lucky
in that I got my start and I started learning
about vulnerabilities before Bug Bounties got super competitive, but it is very competitive right now. And a lot of the times
if you're a beginner and you are looking for the
more simple vulnerabilities, you won't be able to find any
because they're already found by other bug hunters, right? So I recommend starting
with programs that have like a lower competition level, where not so many hunters are looking, train up your skills there. I got my start in a non-profit program and the engineers in that
company in return for my reports, they really coach me on a lot of different web vulnerability
skills and reporting skills, and just in general, acting kind of like a
Bug Bounty mentor for me. So I'm really, really
grateful for that program. If beginners can find a
good non-paying program to participate in and
build up your skills, build up your confidence, it will be a really good
way to start transitioning into the paid programs. If you do wanna start making
money with Bug Bounties. Another vulnerability platform
that I found out recently is called huntr.dev. It rewards people for
finding vulnerabilities in opensource repositories. So it's not just the big
Bug Bounty programs, right? There are companies
running their own programs, there are these open source programs. So there are many, many to choose from. I think as a beginner you
really need to be creative as to where you hunt
because you don't want to be in like the most competitive
programs necessarily. - You know Ben, wrote the intro for this book. He said exactly the same thing. - Go hack on programs
that are not being hacked on by the pros, by the top million dollar hackers, by the full-time Bug Bounty hunters. - If I'm a beginner and I'm
trying to compete against Ben and there's many people like that, the chances of me catching it
as a beginner are far lower. So I love that advice. Any other advice for beginners? - It's definitely getting harder
to succeed in Bug Bounties, but it is possible. Something that I see very
often is that beginners try to look for the same vulnerabilities, the same simplistic vulnerabilities in every single program they hunt for. You quickly realize that you
are run into the same issues of not being the first person
to find the vulnerabilities, and in the bug body world
you don't get rewarded for your duplicate reports, right? - Not for you! - I think this is also
something that NahamSec, really advocates is that in Bug Bounties you really need to find your niche. Your niche could be doing
really good recon like Ben, and try to find out those
really obscure places to hunt for bugs on a program. I always look for things like
IDORs, business logic falls or access control issues, because I found that as I gained more experience looking for those issues, I started seeing the
subtleties of the issues and I started thinking about more ways to bypass access control and prevention techniques, and that became my biggest winner. So I think beginners really
need to try to find a niche instead of using all
the popular techniques and hunting on all the popular programs, because everyone else would
be doing the same thing. - Yeah, so become like an expert
in a specific niche, right? - Right. That's for sure. It's a good idea to explore, you know, the vulnerability worlds more widely when you're first starting off, but don't expect all the
things you do to be successful. Right? I think some people are just better at spotting business logic flaws. Some people are better at
building automation for recon or some people are good
at building, you know, fuzzing machines or automation
apparatus for hunting for actual vulnerabilities. You don't want to be stuck
in the beginner level for every single vulnerability
that you work for. So explore widely, find out what you like, find out your hunting style
and then just specialize in that. - Just thought about this
and I don't how valid it is. Let's say you've found a bug
and I found a bug after you, it would be declared duplicate, but if I want to get experience
I could still put that on my resume, can't I? Because I found the bug. It's something to show employers, right? - Yes, that's for sure. The way I think about it is
that duplicates are just, are valid bugs that are not paid. So that's how I like to think about it. When I was hunting I
got a lot of duplicates, that's for sure. And it's still, you still
worked for it, right? You still found a vulnerability that the company cared about. That's the most important thing. So even if that didn't end
up with some monetary reward, you still get experience, you still get the learning and you still get the
positive feedback that, yes you are doing something
right and you indeed found a vulnerability, you proved yourself as a hacker. - To me it's like if I'm
an employer, let's say, and I want to hire someone and they can show me they've
done all of these attacks and they got recognition, even if they didn't get paid for it, it doesn't matter. It means that they found stuff, it means that they're
proving their knowledge, which is fantastic. - Yeah, that's for sure. I totally agree. - Do you need lots of money to start this? - Not at all. That's what I think I really
liked about Bug Bounties. Well all you need is your laptop, a browser and like a proxy software, let's say Burp community, it's free to download and that's
like the very basic setups. A lot of Bug Bounty hunters I know, purchase a lot of advanced
hardware, software, but that was really not
needed to get started. So when I first got started
in Bug Bounties, and even now, all I had was you know, a laptop, I use Firefox and then Burp community. - You need to have some
knowledge of Linux, right? So I think you mentioned Kali in the book. - Yeah, it's helpful but
it's not really necessary, I would say. And the good thing with
Kali is that it comes with a lot of like
pre-installed helpful tools. But I find that a lot of that
is actually not necessary, for a lot of Bug Bounty
hunters cause it really depends on what kind of bugs you specialize in. I actually don't use Kali, so it's helpful to know a little bit about how to use the command line, but again that's not necessary. Extremely helpful but not necessary. Programming too, I think it's extremely helpful
to know how to program, but not necessary at the same time. - That was my next question, do I need to learn to code? - I know a lot of bug
hunters who are successful and don't program. Learning programming is really useful for starting to learn how
to automate a lot of the, you know, the tedious parts of bug hunting
like reconning or scanning. - Any recommendations, is
it JavaScript, is it Python? Is it go? What language do you recommend
if I wanna learn one, which one would I start with? - So I recommend learning
Python and Bash scripting, because these tend to be the
most convenient for automation. And you can use any of the
online tutorials really. I think I learned programming
by using Code Cademy. There are so many
resources online right now for learning programming. After you get used to like the syntax of a programming language, you can start building a small program to get really used to the language and start using it in a practical way. So in my book I have
a chapter where I talk about how to build a
really simple recon script, step by step. So that's like a really good
example project to start off writing some code to automate hacking. And what I found was that
after I implemented automation into my bug hunting regimen, it got so much more enjoyable and so much faster because I
can actually automate away, a lot of the boring tasks. - Once you've learned to
code you can't go back, cause of exactly that, right? You can create code that
just saves you so much time. So I'm a firm believer
in coding and python and I agree is a fantastic way to start. - That's for sure. And I think, after you start Bug
Bounty hunting a while, you'll actually found that a lot of the tasks are quite repetitive. Like let's say that you are looking for a vulnerability
called subdomain takeover. So what do you have to do for it? To find that vulnerability
is that you have to scan the company's
subdomains and you have to look for certain signatures
on those pages to see if they're vulnerable to take overs. All of that is actually
like automatable, right? Eventually I think I build like a, it is just a single Python
script that was finding all these subdomain takeovers for me, and I didn't have to do anything. It would've been horrible if
I had to look for thousands and and thousands of
subdomains manually, right? And it's just not practical
because someone else would have an automation script and someone else would find the vulnerability
faster than you. That's the real advantage of also making your bug bounties. - Which sort of area do
you think I should start at if I'm a beginner? - The vulnerability that
we're demoing today, IDOR's, are a really, really good vulnerability for beginners to start to find. IDOR's are probably my favorite
vulnerabilities to find because they are so simple, but they can be super impactful. They probably are like my
most found vulnerabilities. I definitely experience
a lot of success focusing on IDOR's and other access control issues. Definitely different bug hunters will have different personalities, right? I preferred IDOR's and
business logic flaws. I really like business logic
flaws as well because they often are not automatable
by either the company or other hunters. They require some knowledge into how the application
should work, right? And a lot of the times it's
really hard to program that and so it requires a human
actually looking into it. The duplication rates for these vulnerabilities are
typically lower as well. A lot of other hunters have had success with other bug types. One of them is Cross-Site Scripting. So Cross-Site Scripting is
like this super common issue that everyone scan for and
every Bug Bounty hunter is looking for, right? But they're also a really complicated bug, that can have a lot of
potential bypass techniques that you could use. So if you get really good
at Cross-Site Scripting and using JavaScript then you can make a whole Bug Bounty career just
with Cross-Site Scripting. I don't really like to
work with this bug type, but I do know that a lot
of people really enjoy it. I know APIs are also
becoming a really big thing. A lot of the vulnerabilities
I found recently, are actually API issues and hacking APIs are becoming
this like whole different area of expertise, right? I know I watched your
interview with Corey. - Historically when you're trying to go after the crown jewels of an organization, which is typically their data, you have to find a way into that network. Once you get into that, then you have to get past their firewall, then you have to find a landing point within a network where
you can pivot around, maybe get domain admin and locate the data and exfiltrate it somehow. The big deal with APIs is they
bypass nearly all of that. - He is like the expert
in hacking APIs, right? He has a book in hacking APIs as well, which covers in depth
how you would like fuzz an API, how you look for different issues in APIs. So I have it in that book as well. I think the big thing with
API hacking is that a lot of your fundamental skills
would naturally transfer into API hacking. So let's say that you read my book and you learn about SQL injection, you learn about IDORs, you learn about access control issues, you can then start learning
a little bit about APIs by reading Corey's book and just naturally
transfer the skills there, because a lot of the mechanisms under the hood actually
works the same way. - When you learn a skill,
it's not lost is it? I mean you can take it
into different areas. I'm really keen to get to do a demo. Would you be able to show us an IDOR demo? - Sure, yeah. IDORs are my favorite
vulnerability defined. - Like what is IDOR? Let's start with the basics. What is it? Why do we care? - So IDORs, the full name is called, Insecure Direct Object Reference and despite the long and
sort of intimidating name, IDOR is actually a very simple
vulnerability to understand. Essentially IDOR is
missing access control. Let's say that example.com
is a social media site that allows you to chat with other users and when you sign up you
notice that your user ID on the website is 1, 2, 3, 4. This website has a page
that allows you to view all of your messages with your friends. When you click on the view
your messages button located on the homepage, you get redirected to
messages, question mark, user ID equals 1, 2,
3, 4 where you can see all your chat messages with
your friends on the website. Now what if you changed the URL in the URL bar to question
mark, user ID equals 1 2 3 3. You notice that you can now
see all the private messages between another user, user 1 2
3 3 and all of their friends. If so, you have found IDOR vulnerability. The reason that you were
able to see the messages of another user is that
there were no identity check in place before the server returns the private information of users, the server was not verifying that you were in fact user 1 2 3 3 or
if you are an imposter, it simply returned the
information as you have requested. IDORs happen when access control
is not properly implemented and when the references to
data objects like a file or a database entry are predictable. - Here we are at PortSwiggers
Web Security Academy. So this is a lab that I really
recommend for beginners. I do believe it's completely free to use and it sort of gives you
a way to practice a lot of the basic vulnerability types. So once you've gotten familiar
with the vulnerability types, the all OWASP top 10, the
IDORs, the A5 vulnerabilities, you can then come here to
this lab environment to for practice. I do have a list of labs
and CTMS that I recommend for beginners. I'm gonna give you the
list and then maybe David, you can post it under on the video. - Anyone who wants to
see the recommendations, I'll put it below. - This particular lab on
PortSwigger Academy is about IDORs specifically. They planted this IDOR vulnerability within this shopping site, and what I really like
about this lab is that they don't really tell you where
the vulnerabilities are. Instead they let you go through
the regular hunting process of finding and discovering
the vulnerability yourself. This website is like kind of simplistic, much more simplistic and the
requests and responses are much more simplistic than you would find in a regular application, but nonetheless it's
like really good practice for beginners. Usually when you hunt on a lab like this, you'll have to like
poke around the website and sort of look for all
the different requests, responses to look for the one IDOR. But for the sake of time, I've already done that
beforehand and I know that in this particular lab the IDOR is located in the live chat functionality. So let's go there. So once we go into the live chat, you can see that there is live chat with like a message box right here. Let's try to send a message here. For some reason the send button
is not really working here, but we could still go
into where the IDOR is, where the vulnerability
is in this application, because it's actually in this
view transcript functionality right here. When I click view transcript here, you can see that, you know, something is downloaded and
you can see that I've actually tried out this lab multiple times already, to make sure that this
demo works properly. Here you can see that
there's several files being downloaded. When I click view transcript and I think the latest one is this file. So three dot txt, was the file that we just downloaded. Just to test that hypothesis, let's go to Burp suite
and turn on intercept. So now our Burp suite is
intercepting the traffic from our Firefox browser and let's click on view transcript again. So this should make Burp Suite intercept our outgoing request so
that it won't be sent to the server right away
so that we can take a look at what our request is doing. And when we click on view transcript here, we can see that, yes, we did see some requests filling out here. What I would do usually is that, once I start using a
functionality that I suspect, is vulnerable to IDOR, I would start looking
at every single request that I'm sending out from my browser as well as coming back in
from the server to scan for things like obvious user IDs, obvious resource IDs and
start switching them out if possible. I would like to add that these
resource IDs and users' IDs, they're not always that obvious, right? They're not always simple numerics, sometimes they are phase 64 strings or short strings that are
derived from the user ID. So there are a lot of possibilities, but the key here is to look
for anything that might be referring to the resource
that we're looking for. If I am looking for an IDOR
that potentially is gonna allow me to read another user's messages, I would look for things like
numbers in the requests, weird strings that I don't know
what it's for in the request as well as anything related
to their user IDs, usernames, emails, and I would start to switch
those out to see if I can access other people's resources. So just from a quick scan here, I don't think this request
looks too suspicious. There isn't anything
similar to a resource ID, besides maybe the session cookie here, but let's continue and
see what we can find. So when we forward this
request to the server, let's see what we get here. So these are not really
related to the demo. Here we can see, this is another host
request that is going out from my browser to the server, right? And I just skipped off a ton of requests because they're simply
not related to this lab and you can tell based
on this host header here. So this is another request, a get request to the endpoint
called download transcript and it's downloading
transcript four dot txt and it's an outgoing request
from our browser to the server. If we continue to intercept
requests and responses, we can find out what this request
returned from the browser. What we can do here also is
that if you don't wanna go through like all these requests, you just want to see this related request and response right away. You can right click on Burp
and click send to repeater, and then this will just
automatically populate the repeater with your request so that you
don't have to use your proxy and then filter through
all the unrelated requests, and you can see that
nothing really happened. In this case, after we send the get request, the server does not actually
return the file right away. There's probably another
request facilitating this process here. Let's continue with the
proxy, let's see what happens. I think something is downloaded. Okay. So something was downloaded there, I didn't quite attach the request, but let's see, open this file. This you can see was the
file that we just downloaded from this server, this vulnerable server, and it just says
disconnected, chat has ended. So I suspect that this is simply what the live chat is giving you. So I think this is basically a transcript for the live chat that we just did. And because we didn't
really send any messages, and we didn't get any
messages back from the site, this is all that's in
the transcript, right? Disconnected, chat has ended. Nothing too exciting. But what I see here is that, at the request that we
were just looking at, at repeater here, we can see that it's sending a request to the download transcript endpoint. Downloading something called four txd. What is this four dot txd, right? Can we possibly exchange this ID out, let's say change it to
one dot txd, two dot txd, does that mean that we
could access someone else's transcripts and see someone
else's track messages? So that's what I wanna try here. Again we can use the repeater
or you can use the proxy as well to intercept the request and then return it back to the browser. Let's do this again and we can turn on intercept again so that we're catching our request now from our browser, and then click view transcript here again and let's say click forward and then we can see this download
transcripts request again. And we can see here like
now the download transcript, endpoint is sending an
endpoint to five dot txd. So that's even more indicative
that the transcript IDs are being incremented. They're probably going
like 1, 2, 3, 4, 5 and I'm, I just happen to be the
fifth user who is using this functionality. Let's see if we can
change it to one dot txd and see what happens, right? I'm not sure if this is
actually gonna allow me to read someone else's messages or
access someone else's resources, but you should always try out
these suspicious endpoints and see if you can find anything. Sometimes it's just incremental
based on your user ID and they tie your user ID to the resource that you can access. And in that case, the application is not vulnerable to IDOR. But you can never be sure
until you try it out. Let's turn off incept now. So when we turn off intercept, we'll just send all the
responses back to our browser. Let's see, it still says five dot txd, I think that didn't quite work. I'm gonna have to try again. You transcript again, sometimes this happens. So what I just did actually was that, I opened up my downloaded file, it says five dot txd and it's still showing me the same result, disconnected, chat has ended. So that means that I'm still
just downloading a transcript for my user session, possibly the last one that I just did and that the IDOR actually
did not go through. In this case I'm quite
sure that the endpoint has an IDOR, right? So that means that there's something wrong with my execution. Maybe I modified the wrong request and that's not the actual
request that is determining which file to return or the
system detected something that I'm not the proper user and I'm not allowed to
access that resource. Sometimes you have to maybe
try and endpoint a few times, try a few different things, try messing with different
requests that are going out from your browser for the same feature. To really pin down which resource or which endpoint you should
really be tampering with. So we see this request
right now again, right? Get download transcript six dot txd and we changed it to one
dot txd the last time, but we immediately turned off intercept. We didn't have a chance to look at what's actually coming
back from the server. So I'm gonna keep intercept on this time and do one dot txd. This time let's look more closely
on what the server returns and see if there's anything
else that we need to tamper with in order to get to our final results. So we click forward again, this is not related, not related. So here somehow the
request is being sent again for six dot txd. I'm gonna change this to one dot txd again and then see what happens. I'm also going to, so something I really
like to do is that I like to send all the suspicious
requests to the repeater, so that I can try out the same
thing over and over again. Once I'm in the repeater, right, I have this request fixed here
instead of like a proxy where requests are coming and going, so I can start messing around with all these different fields like
the cookie session field, the host field, the get field. So the repeater is like
a really good place for in depth like experimentation. And the proxy and the repeater actually, are often the only two tools
that I used in Burp community for my hunting, especially when I'm looking for things like access control issues or business logic errors. Let's click forward again, and let's see what's happening. So I see like the requests
are not coming anymore. Does that mean that our
file is already downloaded? Yes. And you can see that one dot txd is here. So we were actually
messing with the wrong ID, when we did it the first time, and that's all right. I think if we have more time, it's worth going back and looking at those two different requests and see what the difference is there. And maybe from there we can deduce how the application is built, in like a real life application and in a real Bug Bounty scenario, we can sort of try to
decode the application, how it's built from those requests, and then go back to sort of apply that to different endpoints as well. And so I'm gonna open up one dot txt here, drag this here and you
can see that one dot txt, actually contains some information, right? It wasn't the same chat
session that I was on earlier, and it's someone called how
talking to someone else, who can actually find
the user's password here, in plain text. So this is like a really classic, really simplistic case of
IDOR where you can mess with the resource IDs
and actually find out other people's sensitive files, and from there who knows
what you can do, right? And this case you found a password. I've also had IDORs in
the past where I've found different users chat
messages with their friends or their private images. So IDORs are really simplistic but their potential impact is
practically unlimited, right? It all depends on what kind
of IDOR that you look for. And so IDORs can be a really, really powerful technique to learn and a really rewarding bug as well. - It's like trying to find the needle in the haystack type of
thing, is that right? - Yeah, that's for sure. It's a really odd bug where
the vulnerability is so, so simple, but at the same time a lot of sites don't really
prevent it well enough. So the way to prevent
IDORs is that you need to check the user session, right? You need to check the user's identity before granting access to resources. But a lot of websites don't do that well. This is like a huge vulnerability, right? And it is a huge privacy leak, in terms of Bug Bounty severity. this is probably a critical vulnerability, if you can see every single
user's chat messages. - How common are IDORs? Is it still something you find? Is it still a bug that's worth pursuing? - I think a lot of
people assume that IDORS are not super common just because of how simplistic they are, but from my experience they
are super common, right? I'm consistently finding IDORs and so I did full-time Bug Bounty hunting for a few months, and during that time
my most consistent bugs were always IDORs. It's one of those issues that applications do not protect against well. The main cause of IDORs
is that the application is not checking whether you are authorized to download that file, but it simply hands you the
file based on input value, right? This is all cause by applications maybe accidentally not
checking user identity on a certain endpoint
or a certain resource. One of the reasons that
make it so hard to defend against is that it can happen
in all sorts of pages, right? It can happen in pages
that access private data, places where users modify their
private information as well, like password change endpoints. And I've seen it a lot
on API endpoints as well, where an API endpoint is not checking whether someone has a
corresponding API token, before sending back all the
sensitive information just based on the resource ID. Part of the reason why it's
so hard to do well is that, you'll have to be very aware of where all of these
access endpoints are, and you'll have to apply very
consistent access control across all these endpoints. Going back to the API thing, API endpoints are probably
the number one places that I'm finding IDORs at this point. You can look for API
endpoints that returned user information based on, like user ID or session ID as input, and see if anyone can
request that information. If you can access other
users' information. So yeah, my top paying Bounties, were all related to IDORs. Some of them were API endpoints, that gave me access to
a bunch of information. The example that we saw just
now was super simplistic. It doesn't really have
any protections in place. The resource IDs were just
very simplistic numbers, but in the real world, IDORs don't always look like this. For the most part they
don't look like this. A very common way that
applications tend to protect against IDORs is to use
IDs that are hard to guess. So sometimes you can see
applications using really long strings of alpha numerics, and they think the randomness
of that screen alone is going to prevent users from
achieving IDOR, right? But that in itself is
not a complete protection because you're still not
checking the user's session ID or session information. Then if the user can predict
or guess or somehow find out about the unique resource IDs, then they can still
execute the IDORs, right? So in my book I actually talk about a lot of ways to bypass common
protections against IDORs. So I think common
protections against IDORs, they range from just
encoding the resource IDs, to deriving the IDs from
the user's information. So how you can combat that
is that you can learn ways to predict user IDs or derive
user IDs from what you learn from the application. Or sometimes you can also
find leaked resource IDs on other parts of the application and then combine that with IDOR, and then suddenly you can
access every single person's information. As long as the outer
protection is not complete, there are so many things that you can try to bypass that protection. And that's something
that really sets apart an outstanding Bug Bounty hunter from someone who can't find any bugs, is how creative are you
and how many different ways of bypass do you know, when you are faced with an
obstacle on a Bug Bounty program. - If you were starting today, what would you advise yourself to do? Is it like go and register on PortSwigger, like read your book? Give me like a path if
I wanna get into this. - Yeah, for sure. I think the first thing that
a beginner should do actually is to read my book. This is basically a beginners guide to all the vulnerabilities
that are most common in web applications, so that it gives you a
quick start to understanding about all the mechanics
of what you're doing. And then we can do something like sign up for PortSwigger to test your skills out in a simplified environment
and then go hunt on a public program
that's also non-paying, so that you prevent getting frustrated by tons of duplicates and informatives on those really competitive programs. It's worth it to start
investing time into automation as soon as you can. When I was first getting started was that, I did not automate until I
was getting a lot of bounties and I wanted to scale. Before that point, I've already spent tons of time doing repetitive tasks, right? And that took up a lot of
time that I could have spent hunting for other bug types that I could have spent
exploring other parts of the program, and I could have spent learning about different
vulnerabilities, different bugs, and different technologies. Start automating the boring
tasks as soon as possible, would really pay dividends
into your rewards for Bug Bounty hunting. - I think that's great advice. So you've still got an active
blog where you publish, right? - Yes. Vickieli.dev, so that's V I C K I E L I dot D E V. I publish a lot about, mostly about web security
but also different things. Like how do you navigate
a career in InfoSec, how do you write better technical content? Every time I publish a blog post, I tend to announce it on Twitter anyway, and my Twitter handle is Vickieli7. So V I C K I E L I seven. You can always find
whatever I'm up to in terms of InfoSec right there. - That's brilliant. So for everyone watching, please go and follow Vicky on Twitter. Go have a look at her blog, use the link below if
you wanna buy the book. Otherwise go to no starch or wherever your favorite place is. Vickie, thanks so much
for sharing and, you know, taking your knowledge and not
just keeping it to yourself but like putting it on your blog, being involved in the community, sharing your knowledge on Twitter, but also for putting the book together. Really thank you for that. - Thank you so much and thank
you so much for having me. (upbeat music)
