A Modest Proposal Against Cross-Site Scripting Attacks: Clean()

[Update: I posted this and then realized that having it on the client side doesn't solve things, since people can just shoot it over to the server other ways. Oh well... back to the drawing board]

You know, expecting developers to handle every single way of launching a Cross Site Scripting (XSS) attack is way too complex and unreliable. Can we get one of two things:
  • Either the browser makers give us a single nice method, let's call it makeSafe() or clean(), that I can run on a DOM node or string and which will completely remove any unsafe code: someNode.clean()
  • Someone create a client-side JavaScript library that does all this, super modularized and easy, and put it out under a BSD license so everyone can incorporate it into their systems. This library will expose just one method: clean(). This method can run on strings or DOM nodes.
Once we have either of these, we can hook them into blogging systems, Wikis, etc.; you just grab the new content from the user that they entered into a textarea, call clean() on it, and then send it over to the server side.

Practice Safe HTML!
Email Post

Comments

Comfortably Poor said…
At first, I was going to comment that it's not possible to secure things on the client side due to non-browser access modes and the possibility of tampered clients. But then I actually took the time to read (!) your update at the beginning, and I see you already thought of those issues.

I think that mod_security and the project's additional goal of creating a "portable web application firewall rule format" goes a long way towards preventing cross-site scripting.

I recently implemented an overall input-filtering solution for a large e-commerce site based upon the capabilities of mod_security, and our 3rd-party security auditing results have been extremely encouraging.
2:16 PM
Post a Comment