Finding HTML Injection Vulnerabilities

The HTML injection attackers may try to test your web application by injecting arbitrary HTML code into a vulnerable web page. The following page of the bWAPP application shows us a vulnerable login form. Here you can enter any type of HTML injection. The page will execute and render the output. It is called reflected HTML injection because it will reflect the output to the end-user (Figure 10-1). Basically, the user is able to control the input point and inject arbitrary HTML code that may include malicious links, which may trigger more sinister XSS attacks. It is reflected because the HTML code is rendered and controlled by the user. As a penetration tester, you can test a client’s web application by injecting arbitrary HTML code. If it reflects, and is controlled by you, the application has vulnerabilities. The input forms are not properly sanitized.

In this page I have entered my first name in the first text box, but in the second text box I’ve entered this simple HTML code:

You can see the reflected HTML injection in Figure 10-2. The vulnerable web page executes the code and renders it in the lower part of the web page.

Let us open Burp Suite and, with the intercept on, we will allow the data to pass through it. Since the bWAPP application has been made intentionally vulnerable, the form data has not been validated properly; we can read anything that passes through the form fields (Figure 10-3).

Here is the output that shows everything about the POST data, including the cookie and session ID.

Next, we will demonstrate how an HTML injection occurs and how a web page is ripped from top to bottom by getting defaced. Since this type of attack deals with the appearance of the web application, a single page, it may be considered as less risky. As far as the valuable data of the system or the user is concerned, it is indeed less risky; still, it should not be skipped in the penetration testing. Why? It could lead to a bigger attack. A vulnerable web page also shows the user’s session cookie, as we have just seen in the Burp Suite output (code 10.2). An attacker can use it and launch an XSS attack, which could be more dangerous.

Next, in the bWAPP application, we will see how stored HTML injection works. It is stored in the database and then it gets reflected. The basic difference between reflected and stored HTML injection deals with the risk involved. The stored HTML injection is riskier and could be more unsafe. You will see why in a moment.

Let us open the bWAPP stored blog page and enter simple HTML code in the text box. It is reflected on the web page (Figure 10-4).

Granted, it is quite simple and there is nothing new in it, but what happens if we enter a form to submit some credentials there? There lies a great danger. Let us see how it works.

We are going to enter this simple HTML form that will only take a username.

We are not going to make it more complicated. We want to understand the mechanism first. We could have asked for more data from the user, luring them by assuring some false benefits. Once we have submitted the HTML form through that text box, it gets reflected on the web page. Now we will open the Burp Suite and, keeping its intercept on, we will try to capture the data. Our mission is to read and capture all user data that a user submits to that form (Figure 10-5).

Now you can write anything here. I have entered the same word. Simultaneously, I have opened the Burp Suite, keeping its intercept on (Figure 10-6).

Here is the little output that Burp Suite captured.

There are lots of vulnerabilities we have already detected in the application. If we go to the source code, we’ll find that the HTML form has not been encoded properly.

If it was encoded properly, it would look like this:

Another thing is very important here. You can read the data in clear text on the URL. It should have been encrypted. Therefore, Burp Suite also reads the data quite easily and captures everything that has been submitted through the form.

If the HTML form submission process was properly encoded, the bWAPP application stored blog would reflect the web page like Figure 10-7. The attacker is no longer able to exploit that vulnerability.

Exploiting HTML Injection

Sometimes a web application gives users a separate interface to change the color or fonts. The problem is, as a developer you need to use the form to accept the requests from the users. If your form data is not properly validated, encoded, or the HTML scripts are not stripped off, an attacker might take a chance to deface the web site.

For this test, we need another intentionally vulnerable web application: mutillidae. Let us open it and go to the web page, where we can change the color of the page by submitting data (Figure 10-8). While we are changing the color of the page, we inject HTML injection code and see the result.

If this web page form data was properly validated, you couldn’t have submitted anything other than the color value. However, this web application is made intentionally vulnerable; therefore, we can inject HTML injection code and it will reflect the changed web page immediately (Figure 10-9).

This time the code is tricky, as we need to add special characters so that it will reflect the HTML injection effect with the color.

We have used the closing tag and added the HTML injection code after the value of the color. This is another instance of reflected HTML injection. In the next step, we will see how we can do some more damage to the stored blog page (Figure 10-10).

This time we are going to add some moving text on the blog page. The code is like this:

Figure 10-11 displays how we add the HTML injection code to the blog page.

The <marquee> element starts working immediately. In the blog page, we can see the moving text over the other posts. In Figure 10-12, we see the first part of the moving text.

In Figure 10-13, we can see the text is almost disappearing over the other texts of the web page.

Preventing HTML Injection

I have said earlier, HTML injection is not as risky as SQL injection, which we will learn in the next section. However, a penetration tester should have a good knowledge of web structure, especially how the HTML language works.

The request and response cycle often depends on form inputs. Therefore, every input should be checked if it contains any script code or any HTML code. Hence, proper validation is the best solution. Every programming language has its stripping-tags functions. In any case, no code should contain any special characters or HTML brackets—<script></script>, <html></html>. The selection of checking functions depends on the programming language, which is the developer’s job. However, a penetration tester should point it out in the proof of concept.

In the proof of concept, a penetration tester also should mention these unavoidable steps that would prevent HTML injection. Include all types of escaping characters that I have mentioned earlier. This “escape” includes HTML, JavaScript, CSS, JSON, and URLs. The rule is never to trust user input. The HTML escape should be used before inserting user inputs into HTML element content. This rule is applied for attribute escaping in HTML common attributes.

Sanitizing HTML markup with a proper library and implementing content security policy are two important factors that should be maintained for HTML injection prevention.

Bypassing Authentication by SQL Injection

Open the mutillidae application and open the “User Info (SQL) page” (Figure 10-14).

We need to register here as a new user, and I have created a new user account. The user name is “sanjib.” The password is “123456,” and the signature is “I am Sanjib” (Figure 10-15).

As a general user, I am not supposed to view other user accounts’ details and I should not be able to log in as other users, say as admin. If the database is protected, and the web application has no vulnerabilities, a user’s movement is restricted. This is because the SQL query selects only one user when they are logged in. Let us see the code:

Let us study this code minutely. It is a logical statement. The user name and the password should match. It is only true when both statements are true. However, this is an injection point. We can write one statement like this in the input field of the form:

This means we close the single quote of the user name and then pass two hyphens, meaning the rest of the SQL statement is commented out. The vulnerable web application will read this statement as the following:

In such a case, it does not require the password anymore. When the rest is commented out, it conveys the message that the rest is not required. In that case, it gives the accounts detail of that particular user. Now we can build up our query in a manner where the statement is true all the time.

Our query will look like this:

In the preceding statement, if either one is TRUE, the query will work. However, we know the user name; it is true. The OR statement gives another parameter that is 6=6; it always comes out TRUE. So the whole statement is true anyway. After that we have commented out the rest; it means the statement is true for all the records in the database (Figure 10-16).5

Because the application has vulnerabilities, we get all the records of the user accounts due to this malicious SQL injection.

The output is shortened for brevity. We have 23 records altogether.

A statement that is true by necessity or by its logical form is known as a tautology. In SQL injection, the tautology plays a vital role. Let’s return to our original starting point:

Here the word SELECT is known as the projection or the subject of the statement. It selects a field from a table or a group of tables joined together by a union. The word WHERE stands for the predicate of the statement. In the predicate part, we need a series of conditions, because after that it checks whether the statement is true. When we write, SELECT * FROM accounts WHERE username='sanjib OR 1=1 -- ;, it checks the condition at runtime and the query is formed.

Now, in this tautology, we don’t always need the second condition to be like 1=1 or 6=6. Let us see the MySQL Boolean literal page (Figure 10-17).

Here SELECT TRUE OR true equals 1, always. The constants, true and false , are always evaluated as 1 and 0. Therefore, how about this query?

In the input field we can put this value:

It will give us all the records like before. Furthermore, we may want to get one particular row and target that row to get one record. Suppose the attacker doesn’t want all the records; instead, they want to log in as the admin user (Figure 10-18).

How can we make that possible? Well, if we examine the statement minutely, we can get our answer. We don’t need tautology here. Rather, we should concentrate on the user name. In many applications, the administrator uses the name admin as the user name. We can target that, and in the input box we can place this statement:

In an application full of vulnerabilities, the query is formed like this:

It selects only the record of admin. We can safely log in as admin now. The upper right-hand side shows that the user is authenticated (Figure 10-19).

Discovering the Database

One of the key features of SQL injection involves knowledge of the database. You need to know which database is working as the back-end infrastructure. You cannot use the same fuzzing of the MySQL database in Microsoft SQL Server. We can use the Burp Suite tools to discover that information.

Let us first open the mutillidae application and try to log in with any random string as a user name (Figure 10-20).

We have kept the intercept on in our Burp Suite tool and get the HTTP history as the following output:

Watch the last line; we have typed in the random string sadldfjfkg as our user name and tried to log in. The password field was empty.

Now select the random string and add the special fuzzing character by clicking the “Add§” button on the right-hand side. We need to configure our Payloads position at that point so that we can start the attack from there.

Therefore, a single quote ('), a double quote ("), a % character, or a backspace “” character are all treated as escape sequences in MySQL. We can add them as our payloads in Burp Suite later. Before that, we need to select the last line of the preceding code and send it to the Intruder. We check the payloads position first (Figure 10-21). We will check that no special characters are there anymore. That will pave the way to add our payloads separately later.

Click the Payloads button and add all payloads that we will need to inject. We have seen before how to add payloads individually: just keep these characters /, ', "", %.

Now, we have added these special characters as our payloads; after that, we will go to payloads options and add only “error” and “syntax” as our simple string Grep – Match (Figure 10-22).

This will enable us to get all the errors and syntax-errors, from where we will get an idea about the database used in the application. Here we added the escape sequences individually, assuming that the mutillidae application has used MySQL database.

Now, as we have started the attack we have found that all escape sequences have been detected as “errors”; however, two of them have syntax-errors (Figure 10-23).

We can select any of them, and it will reflect the request first (Figure 10-24).

We can click the Response tab beside the Request tab and read the message. In that message, the error reports are shown in detail, where we can gather all the information about the database. Here we come to know that our guess has been correct, as the application mutillidae has used MySQL database as its back-end infrastructure (Figure 10-25). Knowing the back-end database infrastructure will help us in many ways. Now we can pinpoint our research on escape sequences that are particularly used for MySQL. If we had found a different database, our strategy of attacking would be distinctly separate from MySQL.

In this section, I have tried to give you an idea of how SQL injection works, by describing some common examples. I have also tried to explain the basic logical statements and tautology on which the SQL injection attacks are mainly based. There are a few good free resources available over the Internet where you can get more ideas about SQL injection. In Appendix, I will talk about other bug hunting tools and free resources that may help you.