now we're still not done with testing the book and functionality of this website.
Because if you paid close attention
to when we were using that feature originally
you would remember that there was a lot of
data being exchanged between the client and the server
until we ended up at the confirmed page.
And therefore that means there is more tests to be carried out.
And that's why we usually use the feature as is before
we start exploiting it so that we can see the whole
normal flow and therefore in the future even if we discover
a bug we know that there might be more to discover.
So again if I just go to the booking and we're going to
turn on the interceptor we're going to fill anything we want in here.
Just some random data for a random date and click on reserve booking
as you can see this is the original request that we saw
and I told you there is a vulnerability in this but we're
gonna ignore this one and then we tested these parameters in here
in the previous lecture so we're gonna ignore them this time.
We're gonna click on forward. We're gonna click on. Ok.
And now we have another request. So it's a get request.
It's being sent to confirm two dot PHP and we have a parameter called order I. D.
And that order I. D. Is equal to a certain value.
So this is pretty interesting because this parameter
is actually in the middle of a flow.
I'm actually just going to send it to the repeater real quick just to see if
I send this request as is why what kind of response am I going to get?
So as you can see it seems like we're getting a full html page.
I can click on the render in here to actually see the page that we're
getting and this seems very similar to the actual page that we were getting.
So it's the final result that we were
getting when it says the order is spending confirmation
and it shows us the order ID
right here. So now we have a parameter and we have an equal and we have a value.
So as usual you should play it with this value and
try all of the vulnerabilities that we learned throughout the course.
But before doing that this value looks quite interesting.
So it's random characters,
it doesn't seem like it's an actual word and obviously it's not a number.
You can also see that it ends with an equal sign.
And with experience, once you see something that ends with an equal sign,
That is a clue that it might be encoded with an encoding that is called Base 64.
Now the nice thing about Burp, you can simply highlight any text you want
right click and then you can convert that. So you can encode or decode
the selected text.
And as you can see we have base 64 in here and if I'm
suspecting that this text is base 64 I'm actually going to click on decode
to get the original value. And as you can see the original value is an actual number.
And that number corresponds to the order number.
So now we understand that the confirmed dot
PHP file takes a parameter called order I.
D. That is followed by the actual order I. D. But the order I. D. Is encoded.
So in this case instead of seeing the actual number
we were seeing the encoded version of the order I.
D.
So just by being curious and just employing this researcher
or bug hunter mentality before you even try to discover
all of the vulnerabilities that we learned before and before
you start trying to send some payloads in here.
Let's see what happens if we simply request a different order I. D.
So instead of this order idea so this is 69 let's see
if we can load the the order that was submitted before us.
So 68 I'm going to click on send. And as you can see this doesn't work.
So this whole thing broke and we did not get a useful response.
But that's probably because the web application is expecting the order I. D.
To be encoded in base 64. Therefore I'm going to select my order I. D.
I'm going to right click
converse election again
base 64
this time we're going to encode it.
And as you can see now the text actually seems similar to the original one that we had
and it also ends with an equal sign because that's what I said before.
When you see text that ends with an equal sign,
it's a hint that it might be encoded in base 64.
So let's send it like this
and it looks like it worked.
As you can see we're able to access an order that was submitted by someone else.
So in this case someone that is named Deidra
and we can see her email in here and therefore
we're actually able to load orders that were submitted
by another user which we're not supposed to see.
And therefore this is an example of a broken Access control.
And as mentioned before this is a very very common
bug of our 94% of websites are vulnerable to it.
So the fact that we discovered in here is not surprising at all and
that's why in pretty much any bug bounty program that I've seen before,
it will actually be rewarded a bounty for discovering such bugs
because we're able to load data that belongs to other users.
Another thing that should draw your attention is
the fact that we're seeing the order I.
D. In here.
So I want to see if this value can be manipulated by changing the value in here.
So let me just type some normal text like test test and then we're going to encode it
To base 64
and we're going to send it
and the website fails to load.
So this tells me that this order idea that we're seeing in here
is being read from somewhere else.
And therefore if I put any text in here, including javascript or html text,
it's simply just going to break the application.
It's not actually going to be displayed in here and therefore we
can't find html injection or an EX Ss vulnerability in here.
But as you said earlier,
we do have a broken access control vulnerability in
which you will definitely be awarded a bounty for.