20061120

Eradicate XSS Once and for All

Link

A few things I didn't emphasize enough in the previous entry:

  • Use your framework's built-in mechanisms for proper output escaping where possible (<c:out />, h(), htmlentities(), Server.HTMLEncode(), etc.)
  • Do this output filtering for all dynamic output, regardless of where it came from.
  • To the degree possible, use a level of indirection first - particularly with URL's that you feed into an exit page.
  • This is obviously only good for you if you don't intend for users to be able to put in their own HTML. If users need to be able to put in their own HTML, consider using a Wiki markup instead of HTML.

2 comments:

  1. My main frustration with this is that we ought to be able to prevent this sort of attack architecturally, not just programatically.

    Wouldn't it be nice if we were using an environment where we could actually tell the difference between code and data definitively?

    Sort of like setting the stack to non-executable to prevent certain types of buffer overflow attacks....

    Now all we have to do is come up with a new markup language, new scripting language, and get people to adopt them :)

    ReplyDelete
  2. @Security Retentive:

    Please believe me - I certainly agree. My hope is that client-side XML rendering will become more standardized - so rather than send HTML, the server sends XML (data) and an XSLT for rendering it.

    This will also be a big win for accessibility, if XML is a simplified data format, then a braille reader or vocalizer or whatever can "render" data in a more meaningful format, rather than always "top down" - which is not necessarily the way it gets rendered.

    ReplyDelete