Cross Site Scripting Response

I listen regularly to security now, and there has been a lot of talk lately about cross site scripting vulnerabilities on blogs and websites.

For a more detailed writeup of what cross site scripting is than I could ever produce, check out trusty wikipedia.

Aaron's really basic overview

For a really basic overview, here it is. Basically, in html documents (such as this one) you can put client side code (javascript, generally but it can be many flavors) anywhere on the page.

You can completely mix content and code however you want.

Now, years ago, when the web was young, and pretty much a 1 to many broadcast medium. (I post content, you look at content, nothing more) this was not a problem. The only way you could make my server spit out content was to get my ftp credentials.

The problem comes when you accept content from users.. which is all the rage with the young kids ever since... 1995? ; )

So, I have a guest book on my site. If that content is not properly checked, a you could include a line of code that would kick all users that hit that web page to a porn site... or cover it in platypuses. Worse still, you could include a line of code that would have javascript send you a copy of all the user's session cookies.. which would allow you to pose as them on the website.

Not a big deal for your average blog.. but amazon.com? banking? You get the idea.

Solution: uh.. browser manufacturers?.. w3c? turn that stupid crap off!

With current html standards and practices.. there is absolutely zero need for tag attributes that execute code such as 'onclick' 'onmouseover' etc. There is also absolutely zero reason a <script> tag should ever be found mixed in with content. Most useage of both at this point is due to either backward compatibility with really old browsers, or sheer laziness.

geekish crap:
The current DOM implementation allows you to do a couple things. First, you can select any element on a page by its ID attribute. Secondly, you can associate functions and events (such as onclick and onmouseover) with that object in code. ALL of that code can be defined in the header or in external javascript files referenced from the header. Both places that an XSS post can not ever touch.

Doing it this way helps further the cause of separating content (xhtml/xml) and display code (css, javascript etc.) It's something we should be doing anyway, for the sake of good standards, and clean re-usable code.
/geekish crap

Proposal:

an XSSSafe HTTP header. You could make an http header that would be served by Apache and IIS that would trigger browsers to go XSS Safe.

XSS Safe would mean script tags, and event attributes found in the body of a document would never be parsed or interpreted. The browser would just strip them out.

If for some reason, you needed to turn that header off, you could do so (i think) with a meta tag, or with php's header() function.. etc. The point is.. the policy could be set server wide. Admins could specify that the vulnerability would just cease to exist.

That same behavior could probably be changed by a carefully crafted xhtml dtd, or by a voluntary meta tag in html.. there are lots of ways you could just turn the crap off.

Problem

The obvious problem with this... is there's boatloads of legacy code that uses the event attributes, or uses inline script tags. flash's most recent workaround for IE's security policies comes to mind. really.. these things are all over. That doesn't mean they should be, and with each and every one of them.. it's a very simple matter to just move that code to the header.