Finally, our first vulnerability HTML injection now, I already showed you an example of this bug in
one of the first videos of the course, and it's very easy to perform.
That's why we're starting with it right now.
This is first bug that we are going to cover for all the bugs that we were covering.
This course will be asking three main questions.
What is it?
How can we do it and how do we fix it?
These are important questions for us, especially how we can discover a certain buck now, luckily,
HTML injection is not one of those critical vulnerabilities.
However, it is considered a bug.
And we are going to start off by explaining what exactly is it?
So what is it to describe it?
In one sentence we can say HTML injection is injecting HTML code into the website page.
Simple as that.
How exactly does it work?
Well, here's an example.
Let's say we have a very simple Web page that performs only one task.
It asks the client to enter their name inside of a user input field once the person enters their name.
For example, let's say that they entered a name from the application, then outputs.
Hello, Tom.
So we noticed that this application reflects what we input to the page we type something in and the
application processes that input and reflected back in a sentence.
Hello.
Sukkoth could look something like this, we have form where we submit our name and after the form it
will output hello and then whatever we brought inside of our input field in our code example, our name
is reflected here.
But the key part of our code is part.
That is what we have control of.
So then comes the question, what would happen if instead of a regular name, we submit in our code?
In this case, a simple open header of size one pegs and Pesta written between header tags would be
enough.
What would happen to the code on the Web page if we injected this?
What would it reflect?
Well, here is where we decide if the page is vulnerable to the e-mail injection or not.
Our HTML code injected in the page would look something like this.
Once added to this code example, but the question is, how will the website process it?
Is it going to process it as a regular string or will it process it as an HTML code?
If the website process it as an HTML code and it outputs test written in header sites one, then we
can conclude that the Web page is vulnerable to HTML injection and that user input field isn't filtered
well enough to block HTML tags and HDMI code.
OK, this was an example in theory, but right now, let's see how that would look like in practice.