So now that we know there's something here that we can do, we're gonna go to burp proxy
and we're just gonna start the interceptor and
we're just gonna send our adult request.
We're gonna hit search and you can see that
we see the first request that is being sent.
Its search and equal to whatever I typed in here.
The only difference is you can see the percentage
signs and the strange letters such as this one.
This is because it's just due to your l encoding.
So the angle bracket in here for example is being converted to this.
So anyway we're gonna forward this because
we've already tested the search parameter,
the same parameter that we have in here.
That's nothing new. It's nothing exciting. So we're gonna forward it.
We're gonna see that there is another request being made.
We're gonna let that go, it's not within the same domain.
And then if we do that we're going to see that we have another request in here.
So this time we have a parameter called token.
So usually every time you see an equal sign it means that we can send user input after
this parameter and therefore you can again use that
parameter for all kinds of vulnerabilities for X.
Ss for SQL and for a lot of other things.
So you would go ahead and just put it in a different
text editor and just keep it in mind for future testing.
Now if we go another forward and another forward you'll have the page loading again,
you get the same result.
Nothing that fancy.
But what we did so far is we actually discovered another parameter called token.
So
let's copy the token this new parameter
and let's add it to our U. R. L. Here just to the end of the RL
10% token. And I'm actually just gonna set it to something really silly.
So we're gonna set it to La La La La.
What I'm trying to do right now is simply just typing something silly.
So then when I run this I can actually look for my input within the
page and then from there modify it and see what I can do with it.
There was a question mark in here that I introduced from
copy and pasting which is not a very good skill.
So removing the question mark now and I'm hidden enter again.
And what we're gonna do in here we're just gonna
inspect the element to see the code of the page.
I'm going to do control F to find and I'm just gonna look for
la la la la to see if it's been injected on the page.
And unfortunately as you can see it's zero out of zero.
So basically whatever I typed is not being injected within this page.
Now it's not being injected in this page but it
doesn't mean that it's not being returned as a response.
So similar to the way that we use burp proxy to intercept requests.
We can actually use burp proxy to intercept responses
and to do that all we have to do is go to
the options and scroll down and tick this box to intercept responses.
So I haven't modified anything.
I'm doing exactly the same search, we have an injection, it's the alert one.
And then at the end of it we have la la la la la.
I'm gonna hit enter to send that we're gonna
forward and this time we have the response.
So note before every time we used to use the burp proxy we only
see requests because the response option was not picked in the options in here.
So now because I take the option in the options I can actually see
the responses and analyze them here in burp because the response is sent in stages
and the response that we're interested in is actually not going to be visible within
the browser where it will be for for a very short period of time.
And that's why we're using Burp to actually keep the browser trapped as you can see
the browser is trapped and that's why we're going to be able to see it.
So now if I look for la la la la
here is the match.
So you can see that whatever we're typing after
the token is being injected in this specific line.
This line is specifying the content security policy
and you can see that this is set to self. The object source is set to none.
The script source is set to self, which is very, very important.
And then other options we have in here within the content policy and
then after that we have the token is equal to whatever we type
at this stage. You should go ahead and learn more about content security policy.
You can just go on, google look it up and learn how it works.
Or if you're doing courses or if you're doing these live classes,
obviously you'll get introduced to it that way.
So let's talk about this, let's talk about Content Security policy. What is this?
Content security policy is a browser feature
that prevents excess s and other vulnerabilities.
If you look it up, this is the first thing you'll see.
So that should give you a clue already on why we are getting this behavior within
our example why when we type a script we can see that it's being injected.
And we see that the html injection is working as well.
So the web application is treating our user input as code not as user input,
but we can see that the code is not getting executed in this page.
So literally just looking at this line in here should
give you a clue why your script is not working,
even though it's being injected because
the web application is actually misbehaving
and is actually vulnerable and is actually injecting your code as code.
The reason why it's not running because the response is enabling
Content security policy and it's setting the script SRC to self.
So again, like I said, you should go and read about this, but once you do your reading,
you'll notice that setting this flag in the content security policy or
in the CSP means in line javascript or in line scripts are prevented
in this web application.
So even if the web application has an in line javascript,
it's not going to run it because the response is saying do not run in line javascript.
So that's a big thing when it comes to hiking,
especially if you're not a javascript programmer.
If you're stuck at something that you don't understand what it is,
you literally have to google it and learn about it.
Now, it's not always possible to bypass this.
But luckily if you remember we're actually able to
manipulate the value in the token in here,
therefore we can use that to override the value for this security policy.
Instead of having the script SRC in here,
we can actually have an option called script source, E L E N for element.
Now we can use this option to overwrite the normal script source.
So instead of it being set to self, we're actually gonna set it to unsafe in line.
Now again, I didn't just figure this out myself,
this is not me being a great hacker or anything,
if you just read how CSP works and the different options
that you have and the different values for the options,
you'll understand that setting this option will
help you override the normal script SRC.
And setting it to unsafe in line means that you're enabling in line javascript.
So right now my link or my U R. L. Looks like this
and whatever we type in the token, it goes in here,
it goes in this line and therefore we're actually gonna use script SRC element to
actually override the normal script SRC that
is being defined by the web application.
So we're basically just gonna do that instead of token equal to la la la la la,
it's gonna be equal.
So we're just gonna add a semicolon to append to whatever
that is there and we're gonna make it equal to script.
SRC element is unsafe in line.
So let's copy this and let's paste it in here. Hit enter and boom. Here we go.
We have our alert in here.
So that was your introduction to CSP and how to bypass CSP.