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)