Welcome back.
In this video, we're going to take a look at two more examples of HTML injection, and with this,
we're going to finish off with this vulnerability.
Now, before we start off with these examples, it's important to note is that this is not the most
critical vulnerability that we can find on a page.
But we did start with it just because it's simple to perform.
The effect that it can have is, well, with the injection, you can pretty much change anything on
the pitch, you can change the code, you can make it redirect to a different pitch that we saw an example
in the previous video.
So what you can, for example, do is you can create a fake page that looks exactly like the page that
you're testing.
You can add a form, perhaps a log in form there, and then you can redirect the real page to the fake
page that looks exactly the same.
And the user that gets redirected wont really notice anything.
They might type their information, such as usernames and passwords on the fake page and you would be
able to get all of that.
And that is the HTML injection because a regular user won't really see the difference between a real
page and a fake page.
Nonetheless, enough of talking.
Let's get straight into these two examples.
So the first one that they want to show you is once again under the injection.
And then let's go HTML via injection and let's select HTML5 storage here.
We do have some Web storage, and if we type something in in these user input fields and click on ADD,
it will get reflected on this table that we can see on this page.
Now, there are a few things that we might notice right here.
There are a couple of things reflecting.
We have our test getting reflected here and here.
We also get test getting reflected here, but we also get our user agent field getting reflected here.
Now, we will not be injecting this because we already saw an example of injecting the user agent field.
It would probably work and we could probably reflect our HTML code right here.
But let's give it a try.
Under these two types.
So the first thing that we will notice is that if we turn on the intercept and we type something in.
Well, we didn't really intercept anything, our request didn't get interrupted, we simply just added
another test value on this storage.
But even though we can't really intercept this request, we can still try to write HTML code and let's
hope it is right here.
And pasted on this second input tab as well.
And we do get an injection, we just don't get it here, we get it right here.
As we can see, our input got filtered and it simply just added our HTML code as a regular string.
But here, where it also reflects, we got test written in header size one tax.
OK, so this was a simple example.
We got our code right here, so we know that it's vulnerable to the injection.
But let's take a look at more advanced example.
To navigate to that more advanced example, even that one is rather easy.
We can't go to the injection and let's go, for example, to the first one.
And let's go to this one, those back buttons.
Click on that.
Oops, we still have intercept on.
Let's turn it off.
And this is the page that we get once again, no user input felt.
So what are we going to inject?
We can't even see in this text that anything from our headers gets reflected well, besides this one,
which is standard thing on every page that forbids it, we're just going to ignore it at the moment.
But if we read this discussion right here, it says the large back about an image appears automatically
on most pages and they're probably referring to this arrow and this back button right here.
If the image is correct, the user is redirected to the previous page.
The button works by executing a JavaScript statement which sets document location that HSF equal to
the HTTP header refer.
Hmmm, this might already give us enough information if we give it a try, for example, let's turn
on the intercept and we click this back button if we find the refer header, which is right here.
Well, it is correct.
We do get the link to the page that we want to visit, which is the previous page to this one.
Since we click the back button, it will redirect us to the previous page.
And the link to that previous page is in the river of our HTP headers.
But how does that help us?
It doesn't get reflected anywhere on the page.
At least this link doesn't get reflected anywhere on the page.
Or does it?
Well, let's take a look, let's go right here and let's go under the inspect element.
And for to inspect element, to work better, let us just turn off the intercept.
And go back to our those back buttons example.
So here it is, let's go on it and let's try to find the code of this back button.
So usually just by going over these lines of code, you will be able to select different parts of pages.
So let's just select this one since it's the entire page.
Let's go to this one as it also takes our back button inside and let's go to this one next and this
one here, we should be able to find it with open tech, which covers our button, which in our case
is this one right here.
And here's the button.
If we click on lower error, we're going to get this open, a tag that says unclick document, dot location,
dot a trough.
And here is where our referral link gets reflected.
It is right here in our HTML code.
We can see it inside the apex.
But how can we inject right here?
Well, we could try to inject a simple HTML code in the refer button.
But you will notice that it won't work if I type H1 and then test and then close Frontex and forward
the packet, then turn off the intercept and never get back to the page.
Well, we didn't really get our HTML code reflected anywhere.
So could it be that it's not vulnerable?
Well, let's give it a closer look to our code.
So here is our bottom, where we now injected the HTML code instead of the referral link, which relates
to the previous page.
And it looks like this.
So we have open attacks on click document location ref and under the open single quotes.
This is equal to our HTML code, as we can see right here.
So let's copy this line of code.
I'm not sure what they copied, but we're going to give it a try.
Let's go neno HTML code.
But just so we can write our HTML payload right here, and for some reason it copied this, but nonetheless,
I'm just going to type it in so we can see it better.
OK, I wrote the entire code right here, so this is how it looks like.
But we can see that this HTML code that we inject, it belongs to this document, dot dot HSF.
So in order for our HTML code to get processed as an HTML code, we must escape these APACS and this
document application location somehow.
Well, here's what we can do.
Let's try to write our payload down here so it will start with unclick.
Oops.
And I misspelled right here.
So on click document dot location dot a traffic equals Chilpancingo quote in.
The first thing to notice is that this document starts with double quotes.
So perhaps what we can do is we can make it end right here by adding the closing quotes instead of just
starting to write our HTML code right here.
So now perhaps if we write our HTML code,
it would look something like this, right?
So our document altercation should end right here, but we still got our HTML code between the attacks.
So what we can do is we can also close the attacks right here after the double code that we inject it,
we can type closing tags that we have right here and closing a tax.
Now, you might notice some similarities because we pretty much just moved this entire part of characters
right before our HTML code, as you can see right here, here was it before and now we have it here.
So we're essentially making this open a tags with the document location and sooner and as soon as it
ends with this line, we are moving on to our next line of HTML code that we are injecting.
So our final payload will look something like this.
We want to inject this into the page, open OpenEdge one text.
This is our payload.
Let's see if it works, so if we call it.
Go back to page, turn on the intercept.
We can lower this, refresh the page, and under the refer, we didn't really need to remove this link.
We can just append our payload straight at the end of the link.
So let's paste.
And here it is.
We got double quotes, close tags, close APACS, open header, one text, we wrote test and we closed
header one tax.
Lets forward this packet and turn off the intercept and we go back.
Here is our HTML code getting reflected on the page.
We successfully performed HTML injection that we couldn't get to work at the beginning.
And this right here is the leftover code that we pretty much cut off once we injected our HTML code.
And in order for us to take a look at how this code looks in the HTML page, we can navigate to our
button, which is right here.
And here is the open, a text that we have before we closed it right here.
As we can see, this is the first part of our code where we close the double quotes and we close the
attacks.
And down here it processed our H1 headers with test written inside of it.
So it processed it as HTML.
And here is that leftover part that we cut off from this line right here.
So once again, in case you're confused, what we did is we took the original code, which looked like
this.
Once we inject our H1 headers, we moved the closing tags before we type in our HTML code.
Then it closed this entire line of eight tags and it processed our HTML code as a separate line and
it wrote it on the page right here.
So this was a little bit more advanced example HTML injection.
And with this we are done with this vulnerability.
So it was rather easy to perform, as we already mentioned, but it does not have that big of an impact.
The best thing that you can do with this is pretty much change stuff on the page or redirect the page.
Nonetheless, if you want, you can take a look at the other examples of HTML injection on this and
on other pages of our vulnerable virtual machine, you can see there are too many.
Of course, we're not going to cover all of them.
So you can practice this vulnerability on different examples.
And we are going to continue with the next vulnerability in the next section, which is going to be
a more serious and a more dangerous one.
And it is called command injection scene in the next lecture.