Okay. So now that we understand what
is, how it's used and its impact,
let's dive deeper on how it works and how to discover such vulnerabilities.
So this falls under the broken access
control vulnerabilities and therefore the best way
to discover it is to have two accounts and see if you can access information
that belongs to the second account from the first account or if you can log
in as the second account using information or the token of the first account.
So because this is a lab you can't create your own users on it.
But we already have two users,
the credentials for the first user which are
supposed to log in with our winner peter.
And the goal is to try to log into another account on the
target website that has the email of Carlos at Carlos montoya dot net.
So let's open up the lab and go to my account
and let's test the functionality as usual without exploiting anything.
So we're gonna try to log in and we're going to assume that this is a social login flow.
So we're assuming that this is using a third party login prompt from google,
facebook twitter and so on and it's asking you to enter your user name and password.
So as I said earlier the user name is winner and the password is peter.
We're gonna click on sign in
now before redirecting you back to the original
website that you're trying to log in with.
Its telling you that this social login is gonna share
your profile information and your email with the original website.
So the original website is requesting this
information and it's asking you to confirm.
So we're going to click on, continue to confirm.
So now the blog has my profile information and my email
and I should be logged in.
So let's click on my account
and sure enough as you can see it knows my name which is winner
and it knows my email which is winner at dot dot dot com.
Remember I never gave my email to this website but this website
is able to know my email because the third party social login,
assuming it's google
have sent that information back to it because we
authenticated with google using the social login button.
So as usual in a normal pen test or in a normal bug hunt.
Once we test the normal functionality and we see that it works
and we have a good understanding of how it's supposed to work.
The next goal is to analyze what happens when we use this functionality with
burp proxy and see if we can exploit it and discover bugs within it.
So let's log out
and this time we're not going to be intercepting the requests
because I want to be able to see the whole flow.
I want to see exactly what happens
from the point that I click on law again
to do that,
we're going to use the http history tab this tab shows
all of the requests that were sent or proxies through burp.
So right now we have the requests that we previously
sent as we were just testing the website normally.
So I'm going to highlight everything and I'm going to delete it
because I want to see everything from the point
that I used to social login functionality like I said
and now I'm going to go to my account again
and it's going to automatically log me in with my social
media account that I authenticated with just a few minutes ago.
And perfect as you can see right here now we have the whole
authentication flow that was used in order to authenticate me to this website
using the social login functionality.
So we have all of the requests and responses
exchanged between the current website and the third party website
that resulted into logging me in with an account that I
own on the third party website and not on this website.
A lot of this is self explanatory. So we have the host in here.
We have the method that was used to send this particular request,
the U. R. L. Or the end point that the request was sent to
and the status code and the response sent as a result of this request.
So we can see that initially we sent a request
to an end point that is called my account.
We can see the request in here
and we can see the response was 302
and as we said earlier 300 responses mean success.
Then another request was sent
to an end point that is called social dash login.
So we can assume that this was an attempt for
a social login which is exactly what we were doing.
Next request was sent to academy heather
so we can analyze the request and the
response to see if there's anything interesting.
But the next one is actually very very interesting because
we can see from the name we have something called
which is kind of short for authentication
in the request we can see a lot of
information is provided within this request.
Now since this is an authentication flow you should actually
pay more attention to it and try to understand.
Or at least just formulate an idea of what's happening. So we can see a client I. D.
Being sent.
We can also see a redirect you ri which is very
interesting because you can test this for so many things.
We can also see this request is a specifying a
response type and the value for that is a token.
So it's probably asking for a token
and remember what we said earlier.
A token is sent from the social account website or the third party website
to the website that you're trying to authenticate with.
And that token is used to authenticate you.
So we can see that this request is given a client I. D. And is requesting a token.
Now if we look at the response again it's a 300 response meaning it was a success
and we can actually see at the bottom in here
an access token was returned to this application.
So this is what the application is going to use to authenticate us.
So if you continue analyzing the request and go to the
request that is being sent to the authenticate and point,
you'll notice that this request is sent with the email of the user,
the user name and the token that was received as a response to the previous request
to validate that we are the right user.
And this is the request that will actually authenticate us and allow us to log in.
Now I'm saying all of this and we're analyzing all of this just to
give you an idea of a typical authentication flow with all of version 2.0.
This is actually not that important for this
example but it will become very important in future
examples and it is very important for you as a bug hunter or a pen tester.
So keeping things simple,
even real life scenarios before you go and try to exploit more
complex or all techniques which we will cover later on in the course
the simplest thing that you could do in here is change this
email to an email that belongs to another account on this website.
So as you know when testing for broken access control vulnerabilities,
you should have to account on the website and like I said try to log
into the other account or try to
access information that belongs to another account.
So we're trying to see if we can use this
access token that we got from the third party website
for our own email to log in to an account that belongs to another email.
So to do this we're gonna right click this request and send it to the repeater.
We're gonna go to the repeater,
we're gonna replace this email with the target email
which is Carlos at Carlos montoya dot net.
And let's send it.
And as you can see we got a 300 response again meaning success.
So this probably worked but we sent this request
within Burp so we can't really see the result.
We can't actually see if we were allowed to log in to Carlos account.
So to send this request in the browser,
I'm gonna first log out of my current account so you can see I'm logged in as winner at
dot com. Now I'm gonna log out
I'm going to right click my modified request in the repeater
and I'm going to select request in browser in original session.
So this will basically send this exact modified request to the burp browser that I
have running right here and keep in mind I just logged out of that account.
So right now I'm not even logged into anything but this request
is supposed to allow me to log into my own account.
So this is going to give me a unique you are l that will submit this request for me.
I'm gonna copy it
and I'm gonna paste it in the browser
and it seems like it logged me in without even having to log
in because I've actually sent a request login and modified request log in.
So let's go to my account
and perfect as you can see I'm logged in
with a completely different user name which is called Carlos
and my email is Carlos at Carlos montoya dot net.
So now by exploiting the Oo flow,
I'm able to access a completely different account that does not belong to me and I'm
obviously able to access their information so you
can see the user name now is Carlos.
Even though in the request even in the modified
request I sent the user name as winner.
But the main thing is I was able to reuse an access token
that was sent to me as winner
and use it to log in to an account that does not belong to
me by simply modifying the email to the email of the target account.