Testing for HTML Injection (OTG-CLIENT-003)

Revision as of 18:43, 14 December 2013 by Mmeucci (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Brief Summary

HTML injection is a type of injection issue, which occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims.

Description of the Issue

This vulnerability occurs when the user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) the legit from the malicious parts and consequently will parse and execute all as legit in the victim context. There is a wide range of methods and attributes that could be used to render HTML content. If these methods are provided with an untrusted input, then there is an high risk of XSS, specifically an HTML injection one. Malicious HTML code could be injected for example via innerHTML, that is used to render user inserted HTML code. If strings are not correctly sanitized the problem could lead to XSS based HTML injection. Another method could be document.write() Exploitation Notes:

When trying to exploit this kind of issues, consider that some character is treated differently by different browsers. For reference see DOM XSS Wiki

The innerHTML property sets or returns the inner HTML of an element. An improper usage of this property, that means lack of sanitization from untrusted input and missing output encoding, could allow an attacker to inject malicious HTML code. Example of Vulnerable Code: The following example shows a snippet of vulnerable code that allows an unvalidated input to be used to create dynamic html in the page context:

var userposition=location.href.indexOf("user=");
var user=location.href.substring(userposition+5);
document.getElementById("Welcome").innerHTML=" Hello, "+user;

In the same way, the following example shows a vulnerable code using the document.write() function:

var userposition=location.href.indexOf("user=");
var user=location.href.substring(userposition+5);
document.write("<h1>Hello, " + user +"</h1>");

In both examples, an input like the following:


will add to the page the image tag that will execute an arbitrary JavaScript code inserted by the malicious user in the HTML context.

Black Box testing and example

Blackbox testing for HTML Injection is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.

Gray Box testing and example

Testing for HTML Injection vulnerabilities:
For example, looking at the following URL: http://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html

The HTML code will contains the following script:

<script src="../js/jquery-1.7.1.js"></script>
function setMessage(){
 var t=location.hash.slice(1);
 $("div[id="+t+"]").text("The DOM is now loaded and can be manipulated.");
$(document).ready(setMessage  );
<body><script src="../js/embed.js"></script>
<span><a href="#message" > Show Here</a><div id="message">Showing Message1</div></span>
<span><a href="#message1" > Show Here</a><div id="message1">Showing Message2</div>
<span><a href="#message2" > Show Here</a><div id="message2">Showing Message3</div>

It is possible to inject HTML code.


OWASP Resources