we're going to continue today with xs s vulnerabilities and we're going
to cover one that is a little bit trickier than usual.
As you can see this lab is actually target experts.
So it's a little bit trickier than usual.
The problem with this one is the target webpage uses CSP or content security policy.
Now we're going to approach it as if we don't know this because they don't like
to just cover what it is and show you how to solve this right away.
We usually approach things in a black box manner,
assuming we don't really know how that pages program.
That's how it works.
So we're simply just gonna load the page assuming that you're doing a pen test
or a bug hunt on this particular domain once the page loads as usual.
I know I say this in every lab but I can't stress it more.
You really have to click on every button.
You really need to manipulate every possible your L parameter
and you really want to manipulate every single input.
You see the visible and the hidden ones.
But now we're basically just going straight away
into the examples because we've already done this.
I don't want to waste your time.
So again, if you're testing this, you'll basically just use it as a search,
see if the functionality works.
It works. Test the back button.
We've seen how a number of times
you actually discovered vulnerabilities in the back.
Once you're tested like this,
obviously you want to taste it for excess s SQL injections.
All kind of vulnerabilities.
I know that this is vulnerable to excess S That's why I'm going to focus on that
now. Usually at the start we'll try to just do html injection.
So for example, we just do B and do a test and a slash B.
And then as you can see right now from the get go,
we can see that the B the test instead of it being normal.
So if we just do a normal search for test, you'll see that it's normal.
But because they added the B tags, the test in here is actually bowled.
So if we inspect this element,
we will see that the tags we injected,
the tags are being injected properly and therefore
the formatting of the text is changing.
So that means we are able to inject html code.
So this is basically html injection in a bug bounty or in a pen test.
This is a valid vulnerability in the bug bounty
will be awarded for it in most cases and
in a pen test will definitely include this in
your report because it is a valid vulnerability.
Usually when you find the html injection,
we would always try to see if we can
actually inject javascript in this html because we're basically able
to inject code into the source code of the
page and the web browser is accepting this text,
whatever we're typing as code and it's rendering it.
So that is great.
So if we manage to inject javascript which is a programming language,
not a markup language like html,
we'll actually be able to do so much on the
web page and it's a much more dangerous vulnerability.
So in a pen test or in a bug bounty,
you'll get a much higher credit whether it's in terms of money
or in terms of just a good finding in a pen test.
So
in order to test if we can inject javascript,
we can start with a very simple javascript code.
I always like to do things starting with the simplest case,
not just with javascript with everything.
Even if you know if you've done my courses and you see my network hacking and stuff.
I always do the simplest scenario first.
And then I build up on it because when things go wrong in a simple scenario,
it's easier to know what went wrong.
So we try to change one variable at a time and build up
on the simple scenario until we reach the goal that we want.
That's why we test html injections first because they're the simplest.
And then we build up on it with a very simple javascript
injection as well to see if we can get it to work.
So a very simple javascript injection would be the script alert one.
So this will basically show an alert message that will
have number one as the content of the alert message.
Now, if I click on search, you'll see that nothing happens. So nothing works now.
We can see actually here.
Whatever I typed is being injected in here after the search parameter.
We don't see the text in here. So whatever I typed is not being displayed in here.
But we also didn't see an alert message. So let's inspect this part of the page.
So right click and inspect
and you can actually see our script is being injected exactly
as is So it's not being formatted in any way,
shape or form.
It's not being edited, it's not being removed, it's not being filtered,
but for some reason it's not working on this page.
Usually if the target web page is implemented properly
and is actually understanding that whatever you typed in here in the search is
actually part of the search and it is not part of the code.
You should actually see that text in here. Similar to when we search for test.
For example, in this example, when we search for test,
we've seen that the pages saying you are searching for test.
When we search for a code. When we try to inject the script code,
we actually don't see the script code in here. So this gives me a hint
that even though that this did not work,
the page still does not understand whether whatever I injected whatever I typed
in this box is actually part of the page or part of the
code because if it knew for sure it would have displayed it in
here for me because the right behavior for this functionality is to say,
search results for and display whatever the user input is
when I input the script in here, I'm not seeing it in there.
This just gives me a hint that the web application
does not know what to do with what I entered.
Is it code? Is it not code? Should I display it in here?
Should I execute it as part of the page?
It's kind of confused about it, and therefore when I see this, I'll be like, okay,
I'm actually going to spend more time on this input because I feel like
I can manipulate it in some way and get it to actually run javascript.