Hacking Web Apps

Understanding HTML Injection

HTML injection is a basic security weakness in which data (information like an email address or first name) and code (the grammar of a web page, such as the creation of script tag elements) mix in undesirable ways.

An XSS attack rewrites the structure of a web page or executes arbitrary JavaScript within the victim’s web browser. XSS comes into play when the visitor can use characters normally reserved for HTML markup as part of the search query.

Each of the previous examples demonstrated an important aspect of XSS attacks: the context in which the payload is echoed influences the characters required to hack the page. In some cases, new elements can be created such as script tag or iframe. In other cases, an element’s attribute might be modified. If the payload shows up within a JavaScript variable, then the payload need only consist of code.

More vicious payloads have been demonstrated to:

• steal cookies so attackers can impersonate victims without having to steal passwords;
• spoof login prompts to steal passwords (attackers like to cover all the angles);
• capture keystrokes for banking, e-mail, and game websites;
• use the browser to port scan a local area network;
• surreptitiously reconfigure a home router to drop its firewall;
• automatically add random people to your social network;
• lay the groundwork for a Cross-Site Request Forgery (CSRF) attack.

Form Fields

Forms collect information from users, which immediately make the supplied data tainted. The obvious injection points are the fields that users are expected to fill out, such as login name, e-mail address, or credit card number. Less obvious are the fields that users are not expected to modify such as input type=hidden or input fields with the disable attribute. A common mistake among naive developers is that if the user can’t modify the form field in the browser, then the form field can’t be modified.

Why Encoding Matters for HTML Injection

The previous discussions of percent-encoding detoured from XSS with demonstrations of attacks against the web application’s programming language (e.g. Perl, Python, and %00) or against the server itself (IIS and %c0 %af). We’ve taken these detours along the characters in a URI in order to emphasize the significance of using character encoding schemes to bypass security checks.

The angle brackets (< and >), quotes, and parentheses are the usual prerequisites for an XSS payload. If the attacker needs to use one of those characters, then the focus of the attack will switch to using control characters such as NULL and alternate encodings to bypass the web site’s security filters.

Probably the most common reason XSS filters fail is that the input string isn’t correctly normalized.

Often the impact of HTML injection hack is limited only by the hacker’s imagination or effort. Regardless of whether you believe your app doesn’t collect credit card data and therefore (supposedly!) has little to risk from an XSS attack, or if you believe that alert() windows are merely a nuisance—the fact remains that a bug exists within the web application. A bug that should be fixed and, depending on the craftiness of the attacker, will be put to good use in surprising ways.