Month of Myspace Bugs, Yuss!

After the month of the browser bugs, the month of the kernel bugs, the month of the apple bugs and the month of the php bugs this month is the month of the myspace bugs. While this initiave takes itself a bit less serious and also parodies the other month-of's it's still interesting. They show a lot of nice application level exploits and explain wether they are hard or not and why. So check it out if you're into XSS, phishing, etc. Also make sure you check their recent post on operational security

XSS defense in depth measures

Last night i was thinking about defense in depth against XSS. It is not always an option to rewrite big parts of an application (since it's a commercial package for instance). So I am searching for methods which could be implemented easily using for instance one (server-side) include at the start of each page. These are the options I thought of. If anyone has additional defense in depth methods I'd really like to hear.

1. Referrer checking
   If some page should only be called from your own site, you shouldn't allow other sites. Of course this is no real protection since people use (stupid) firewalls which block the referrer. Also, it does not stop attacks from the same site (using XSS for example).
   
2. Disallow certain characters in parameters
   This might not be able for every site but if it is it might help. You can of course forbid certain characters like <. This might not prevent all attacks but it might keep a few out of the door. Of course this is only possible if your site doesn't need to accept less than signs.
3. HTTPOnly cookies
   While this doesn't help preventing XSS it helps against one of the standard exploits. If you use HTTPOnly cookies MSIE and Firefox 3 users can't have their cookies (=sessions) stolen. This prevents a remote takeover from a session. However, one can still put a script in the payload which already does nasty stuff, or hijack the session using some sort of XSS shell.
   
4. Advanced referrrer checking
   You could improve on referrer checking by defining a graph of pages. In this graph you'd need to mention all allowed steps from one page to the next, and only allow those. Of course this is rather labour intensive. Alternatively you could `record' steps taken for a month or so and base your graph upon that.
5. Parameter checking
   If the parameters are well-defined you could add an extra kind of software firewall in front off the application which checks wether the values contain ``valid'' values (for instance, wether id's are integers). Again this is labour intensive, and again it might be possible to automate this by recording currently used values and doing some smart heuristics on them.
6. Crippling Javascript
   This won't help against XSS either, but like HTTPOnly cookies it will reduce the impact. For instance you could overwrite the XMLHttpRequest object if you're not using it, so it can't be used in any exploit

So now it's your turn, do you have any simple methods which can improve the security? (I'm aware that the only solution is to code secure applications)

XSS in Blogspot

Yesterday RSnake posted about a ``XSS'' hole in Blogger. I don't really think it's XSS if you can only inject on your own blog, but whatever. It didn't sound too interesting that it was safari-only either, so I decided to extend the exploit to MSIE and Firefox, so here it is:

http://nightofthexss.blogspot.com/

For the exploit I use that Firefox actually parses comments correctly and that MSIE has support for conditional comments.

Kudos to Jose Avila for the original exploit.

Month of the Apple Bugs

I have a few hippie friends who use a Mac. They used to claim their OS was safer, but now they can't anymore ;). It's the Month of the Apple Bugs. But since I like my RSS reader I decided to make a feed, enjoy!

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 ;) ).