-: Welcome back
and it is time that we cover another version access attack.
Which is called Stored XSS.
In the previous video, we covered the Reflected XSS
and this is pretty much the same thing.
It is the same vulnerability.
Just this time, our code will get stored
on the server site and it is more dangerous
because everyone that visits that page
from the time that we injected our JavaScript code
will also run that code.
You don't have to send them any link or anything else.
The code will run by itself as soon as they visit that page,
and we already know where we can find the example
of Stored XSS.
So let us just go to our Meta Portable IP address
in the DVWA and let us log in.
As usual, make sure that your burp suite is running
and make sure that the intercept is turned off.
I will zoom this in
so we can see everything better,
and let us first navigate
to the DVWA security and check low right here.
After we do that, let us submit and go to the stored XSS.
So once again, this is the same vulnerability.
We want to inject JavaScript code in user input fields.
So what do we got here inside of our application?
Well, it asks for name and message.
Hmm, vulnerability stored cross eye scripting.
And why is this stored?
Well, if we take a look at down here
it seems that someone already made a comment,
name is test and the message or comment says
this is a test comment.
And you might already see why this is stored.
It is already on the page
and anyone that visits this page will also see this comment.
So this is something that everyone that loads the page,
will also load this comment as a string.
But what happens if we try to,
for example, input JavaScript code?
Will they also load the that?
Yes, they will.
Let me show you an example.
First, let us create a regular comment.
So I'm just going to type Alexa and Hello there.
Can you see me?
And let's sign guest book.
And we can see right here our comment has been added,
so everyone will also be able to see this.
But what happens if we, for example, try to
inject JavaScript code?
Let's go with simple alert Script.
So script alert, and if we continue typing, we will notice
that we cannot really type anymore in this field.
So it could be that this field is limited to only
certain amount of characters.
So let's just leave that on test and let's try
to inject the code here.
If I go onto the script, then alert and I alert one
And I closed the script tag,
here we can input the entire script.
So let's sign Guestbook and our JavaScript code executes.
There is no user input filtering.
Therefore, since we are on low level
we will inject a simple code as alert one.
Now the good part about this is that now
since this comment has been added to this list,
every time we visit that page
every time they will execute our code,
or we will execute our code.
So we don't have to type it once again
as we had to with access reflected.
Remember, if we type inside the reflected
a simple alert script,
It'll execute.
But once we change a page and go back
to the access reflected, there is no code running.
However, on stored, we will run this code every time.
And that is why it is more dangerous.
For example, if you did the same attack as
from the previous video where we stole cookies
if you inject that code here, then anyone that
visits this page, their cookie will be sent to you.
And you can then perform session hijacking or something else
if cookies aren't configured correctly.
And this will also happen if we log out of the page.
For example, if I go log out and I go back to the page,
and go back to the access stored this executes once again.
Now if this starts getting annoying
because you want to start testing other examples as well,
what you can do is you can go
to setup right here and create or reset database.
Once you click on this button
navigate back to XSS stored, you will no longer
have the comments that we added in this video.
You will only have this test comment that is there
by default.
Okay, great.
Now let us take a look at the medium level security.
So if I go on medium, submit, go back
to the XSS stored and I try to input right here.
Hmm, it still seems to be limited characters
so we can type longer words than this.
Let's give it a try right here.
So script alert one, and here we can name test.
Hmm. It doesn't work.
It seems that we get these slashes before our single quotes.
So let's take a look at this source code just
to see what is happening inside of our fields.
And it tells us right here in the comments
that this code right here sanitizes the message input
or in other words the comment input.
And this sanitizes or filters the name input.
So it seems that we have this HTML special chars function
onto our comment.
And usually once you have that,
there will be no SSX vulnerability
since it filters all the characters that you
can use to perform access attack.
So most likely this part doesn't have any vulnerability.
So message input or comment input is not
something that we are going to try to attack.
But what about this name input?
It only has this string replace regular script
with empty space, which we saw in the previous video.
We can simply just bypass this with capital script tech.
But there is another problem that we encounter.
We cannot specify more than a couple characters
in the name field.
Is that something that we can bypass?
Well, if I type like this
I will not be able to type more than this.
But if I go and inspect element of this page,
I find the name input right here
and I can do that by going right here on Dev
navigating to here, navigating to form.
Then from the form, this table
and I want to select this name input right here.
So let us give it a try and see which one it is.
It is this first one.
And if I click on this last arrow
we can see right here that once we select
the name input field,
right here we got the max length of 10.
Is that something that we can change?
Well, let's give it a try.
If I select that and instead of 10 I type 100
press enter and I try to continue typing.
Well now it works.
We navigated to this field.
We found the input name field and it said the
max land for 10, but we just added another zero
and now we can type even more characters.
So let's give it a try.
Remember the only filtering that is inside of
the name field is the script text.
Let us make it capital.
And here we can type anything
since we know that this is most likely not vulnerable
to the access attack.
And if I click on sign guest book, there it is.
Here is our access vulnerability
and that is all about stored XSS.
It is completely the same as the reflected XSS,
just this will get stored on the server page
and anyone will load it once visiting that page.
Great. Now that we covered XSS,
in the next video I want to talk
about a small vulnerability that many penetration
testers skip when testing
for web application vulnerabilities.
And that is called HTML injection.
And we are also going to mention why we should never
skip checking for the HTML injection.
See you in the next video.