bWAPP Reflected (GET) HTML injection
In this blog, I’m going to explain about HTML injection vulnerability and how to test a vulnerable web application against this vulnerability. Just a note I’m not writing this because I’m an expert on web pen-testing. On the contrary, I’m learning this subject and it encourages me to keep going with my experiments. However, I think this will help you to get an idea of HTML injection.
What is HTML injection?
HTML injection is a web security vulnerability that is very similar to the Cross-Site Scripting vulnerability. The delivery mechanism of these vulnerabilities is exactly the same but the injected content in HTML injection is pure HTML tags, not a script like in XSS. HTML injection allows an attacker to inject malicious HTML code through vulnerable web applications that can result in changes in the website’s design and its information, which is displayed to the victim.
Malicious code that attacker is being sent during the exploitation maybe a few simple HTML tags, a whole fake form or an entire HTML page. According to the way that the attacker uses this vulnerability may differ the impact of the exploitation. Changing the website’s appearance is not the main concern in these attacks. If the attacker is able to steal a person’s identity, then the impact will generally be critical.
What are the types of HTML injection attacks?
1. Reflected HTML injection
2. Stored HTML injection
Reflected HTML injection
Reflected HTML injection is the simplest form of HTML injection. It arises when an application receives data in HTTP request and includes that data within the immediate response in an unsafe way.
There are three main types of Reflected HTML injection attacks. These are:
· Reflected GET HTML injection
· Reflected POST HTML injection
· Reflected URL HTML injection
Reflected GET HTML injection
To illustrate how you can check a website for HTML injection vulnerability, I used the following.
bWAPP — a buggy web application.
Security Level — LOW
- Let’s enter some random values to the text fields to check what happens.
As you can see, the application echoes the supplied inputs in the URL and the web page.
2. Assuming the application doesn’t perform any other processing of data, we’ll inject any HTML code into the vulnerable text fields.
If another user of the application requests the attacker’s URL, then the malicious code will execute in the victim’s browser.
An attacker can be creative as much as he/she wants to trick the victim to enter malicious URL which seems legitimate, in the victim’s browser. To do so he can use social engineering or other interesting techniques.
Security Level — MEDIUM
- As the first step, let’s enter some values to the text fields.
After changing the security level, inputs are reflected as it is in the page without the execution of the malicious code. So, we will try something new to attack to the page.
To get some hints let’s look at the source code.
When we see the source code, it looks like “<” & ”>” characters are replaced with encoded HTML entities. But without that characters, our code won’t be rendered by the browser.
HTML Entity Encoding
HTML Entity Encoding is a common technique to mitigate HTML injection and XSS attacks. However, there’s no way to attack by decoding the HTML entities. So, we will see what we can do in order to bypass the built-in HTML detection module.
A double encoded URL can be used to perform the attack. In this technique, the first decoding process is performed by HTTP protocol and the resultant URL will bypass the HTML/XSS filter since it has no mechanism to improve detection.
2. As the second step, we’ll use the URL encode twice to encode the malicious code.
3. Now we can intercept the request and replace the encoded value with double URL encoded code and check whether it is working fine.
As a result of the bypass, we can clearly see the source code has changed. Now we can move to the last step.
- Forward the altered request to execute the injection.
