HIQR for the SPQR

Friends, Romans, coding devs, lend me your eyes. I’ve created an HTML Injection Quick Reference (HIQR). More details here.

It’s not in iambic pentameter, but there’s a certain rhythm to the placement of quotation marks, less-than signs, and alert functions.

For those unfamiliar with HTML injection (or cross-site scripting in the Latin Vulgate), it’s a vuln that can be exploited to modify a web page in a way that changes the DOM or executes arbitrary JavaScript. In the worst cases, the app delivers malicious content to anyone who visits the infected page. Insecure string concatenation is the most common programming error that leads to this flaw.

Imagine an app that allows users to include <img> tags in comments, perhaps to show off cute pictures of spiders. Thus, the app expects image elements whose src attribute points anywhere on the web. For example:

<img src="https://web.site/image.png">

If users were limited to nicely formed https links, all would be well in the world. (Sort of, there’d still be an issue of what content that link pointed to, whether obscene, copyrighted, malware, multi-GB images that would DoS browsers or sites they’re sourced from, and so on. But those are threat models for a different day.)

There’s already trouble brewing in the form of javascript: schemes. For example, an attacker could inject arbitrary JavaScript into the page – a dangerous situation considering it would be executing within the page’s Same Origin Policy.

<img src="javascript:alert(9)">

Then there’s the trouble with attributes. Even if the site restricted schemes to https: an uncreative hacker could simply add an inline event handler. For example:

<img src="https://&" onerror="alert(9)">

Now the attacker has two ways of executing JavaScript in their victim’s browsers – javascript: schemes and event handlers.

There’s more.

Suppose the app writes anything the user submits into the web page. We’ll even imagine that the app’s developers have decided to enforce an https: scheme and the tag may only contain a src value. In an attempt to be more secure, the app writes the user’s src value into an <img> element with no event handlers. This is where string concatenation rears its ugly, insecure head. For example, the hacker submits the following src attribute:

https:">alert(9)

The app drops this value into the src attribute and, presto!, a new element appears. Notice the two characters at the end of the line, ">, these were the intended end of the src attribute and <img> tag, which the attacker’s payload subverted:

<img src="https:">alert(9)>">

A few more tweaks to the payload, such as creating some <script> tags, and the page is fully compromised.

HTML injection attacks become increasingly complex depending on the context of where the payload is rendered, whether characters are affected by validation filters, whether regexes are used to deny malicious payloads, and how payloads are encoded before being placed on the page.

SPQR (Senātus Populusque Rōmānus) was the Latin abbreviation used to refer to the collective citizens of the Roman empire. Read up on HTML injection and you’ll become SPQH (Senātus Populusque Haxxor) soon enough.