Thursday, April 12, 2007

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)


Eamon Nerbonne said...

Nice post ;-).

Something as simple as a page counter will make injections slightly more complex (and perhaps impossible in combination with other protections). This counter you might embed in the cookie and various other locations to make tampering more difficult. This is of course simply a type of call-graph enforcement.

Anonymous said...

Good fill someone in on and this mail helped me alot in my college assignement. Gratefulness you for your information.

Anonymous said...

Nice fill someone in on and this mail helped me alot in my college assignement. Thank you seeking your information.