Intro
Friends, Romans, visitors, lend me your eyes. I’ve added an HTML injection quick reference (HIQR) to the site. 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 vulgate), it’s a vulnerability that enables an attacker to modify a page in order to affect the behavior of a victim’s browser. As the name suggests, the attacker injects markup or JavaScript, usually via a form field or querystring parameter, into a string that is then re-displayed by the app. 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 permits users to write tags in posts to show off cute pictures of spiders. The app expects users to add images with src attributes that point anywhere on the web. For example,
<img src="http://web.site/image.png">
Were users of the app to limit themselves to nicely formed http: or https: schemes, all would be well in the world. However, there’s already trouble brewing in the form of javascript: schemes. For example, a malicious user could inject arbitrary JavaScript into the page — a dangerous situation considering the JavaScript will be executing within the Same Origin Policy of the web app.
<img src="javascript:alert(9)">
Then there’s the trouble with attributes. Even if the site restricted schemes to http: or https: a (not-at-all) devious hacker could add an inline event handler, for example,
<img src="http://&">
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 http: or https: scheme and they only allow visitors to define a src value. In order to be more secure, the web app writes the src value into an element that’s guaranteed to not have any event handlers. This is where string concatenation rears its ugly, insecure head. For example, the hacker submits the following src attribute:
http:">alert(9)
The app pops 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 tag, which were subverted by the hacker’s payload:
<img src="http:">alert(9)>">
HTML injection attacks become increasingly complex depending on the context where the payload is rendered, the characters that are stripped or escaped by data validation filters, the patterns used to detect malicious payloads, and the encoding of the payloads and the page. Check out chapter 2 of HWA for more background on these situations.
You’ll find more info on this blog in articles with an “html injection” category or tag.
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.