An ancient demon of web security skulks amongst all developers. It will live as long as there are people writing software. It is a subtle beast called by many names in many languages. But I call it Inicere, the Concatenator of Strings.
The demon’s sweet whispers of simplicity convince developers to commingle data with code — a mixture that produces insecure apps. Where its words promise effortless programming, its advice leads to flaws like SQL injection and cross-site scripting (aka HTML injection).
We have understood the danger of HTML injection ever since browsers rendered the first web sites decades ago. Developers naively take user-supplied data and write it into form fields, eliciting howls of delight from attackers who enjoyed demonstrating how to transform <input value=”abc”> into <input value=”abc”><script>alert(9)</script><”">
In response to this threat, heedful developers turned to the Litany of Output Transformation, which involved steps like applying HTML encoding and percent encoding to data being written to a web page. Thus, injection attacks become innocuous strings because the litany turns characters like angle brackets and quotation marks into representations like
" that have a different semantic identity within HTML.
Here is a link that does not yet reveal the creature’s presence:
Yet in the response to this link, the word “search” has been reflected in a
.ready() function block. It’s a common term, and the appearance could easily be a coincidence. But if we experiment with several
source values, we confirm that the web app writes the parameter into the page.
A first step in crafting an exploit is to break out of a quoted string. A few probes indicate the site does not enforce any restrictions on the
source parameter, possibly because the developers assumed it would not be tampered with — the value is always hard-coded among links within the site’s HTML.
After a few more experiments we come up with a viable exploit.
There’s nothing particularly special about the injection technique for this vuln. It’s a trivial, too-common case of string concatenation. But we were talking about demons. And once you’ve invoked one by it’s true name it must be appeased. It’s the right thing to do; demons have feelings, too.
Therefore, let’s focus on the exploit this time, instead of the vuln. The site’s developers have already laid out the implements for summoning an injection demon, why don’t we force Selector to do our bidding?
Web hackers should be familiar with jQuery (and its primary DOM manipulation feature, the Selector) for several reasons. Its misuse can be a source of vulns (especially so-called “DOM-based XSS” that delivers HTML injection attacks via DOM properties). JQuery is a powerful, flexible library that provides capabilities you might need for an exploit. And its syntax can be leveraged to bypass weak filters looking for more common payloads that contain things like inline event handlers or explicit
In the previous examples, the exploit terminated the jQuery functions and inserted an
alert pop-up. We can do better than that.
The jQuery Selector is more powerful than the CSS selector syntax. For one thing, it may create an element. The following example creates an
<img> tag whose
$("<img src='x' onerror=alert(9)>")
Or, we could create an element, then bind an event to it, as follows:
<img> tag. (The indexes may differ depending on the page’s HTML; the technique is sound.)
RegExp (regular expression) object. Even better, use the slash representation of
RegExp, as follows:
/</.source + "img" + />/.source
Or just ask Selector to give us the first
<img> that’s already on the page, change its
src attribute, and bind an
onerror event. In the next example we used the Selector to obtain a collection of elements, then iterated through the collection with the
.each() function. Since we specified a
:first selector, the collection should only have one entry.
Maybe you wish to booby-trap the page with a function that executes when the user decides to leave. The following example uses a Selector on the
I’ll save additional tricks for the future. For now, read through jQuery’s API documentation. Pay close attention to:
- Selectors, and how to name them.
- Events, and how to bind them.
- DOM nodes, and how to manipulate them.
- Ajax functions, and how to call them.
Selector claims the title of Almighty, but like all demons its vanity belies its weakness. As developers, we harness its power whenever we use jQuery. Yet it yearns to be free of restraint, awaiting the laziness and mistakes that summon Inicere, the Concatenator of Strings, that in turn releases Selector from the confines of its web app.
Oh, what’s that? You came here for instructions to exorcise the demons from your web app? You should already know the Rite of Filtration by heart, and be able to recite from memory lessons from the Codex of Encoding. We’ll review them in a moment. First, I have a ritual of my own to finish. What were those words? Klaatu, bard and a…um…nacho.
p.s. It’s easy to reproduce the vulnerable HTML covered in this article. But remember, this was about leveraging jQuery to craft exploits. If you have a PHP installation handy, use the following code to play around with these ideas. You’ll need to download a local version of jQuery or point to a CDN. Just load the page in a browser, open the browser’s development console, and hack away!
$s = isset($_REQUEST['s']) ? $_REQUEST['s'] : 'defaultWidth';
/* jQuery Selector Injection Demo
* Mike Shema, http://deadliestwebattacks.com
$("#main-panel").addClass("<?php print $s;?>");
<a href="#" id="link1" class="foo">a link</a>
<input type="hidden" id="csrf" name="_csrfToken" value="123">
<input type="text" name="q" value=""><br>
<input type="submit" value="Search">
<img id="footer" src="" alt="">