Content-restrictions and XSS
I have been thinking about this for quite a while, but one of the hardest things to get right is filtering out malicious content if you are a webmaster. Really, the hardest part is that you often have no idea what the browsers will or won’t render. It’s simple enough to remove a script tag but what about the JavaScript directive? As the XSS Cheat Sheet shows, there are potentially hundreds of varients (many of which may yet to be uncovered) and many more to come as browser technology evolves. So one of the things I proposed to Gerv from Mozilla (Firefox) quite a while back was to create a concept of filtering done at the browser level instead at the server level. I can be as diligent as I want to, but as Google proved, even if you strip out all HTML you can still get hit by things like the UTF-7 XSS vector if you don’t know what you’re doing.
That said, I think there is a way to help mitigate the risk by applying a content-restriction at the browser level. It stands to reason that as a webmaster, I know my site better than anyone else. Let’s say I run a rather large website that is trusted. I know that my site is trustworthy except for places that may allow user submitted content. If I can somehow notify the browser that a certain page is considered unsafe, it can protect itself. Obviously, it shouldn’t allow the webmaster to decrease the browser security settings, but it should allow them to increase them if they are concerned about the safety of their users. It was a work in progress eventually to be submitted to the WHATWG but Gerv gave up on it because of lack of resources and it was a massive undertaking.
This wouldn’t solve things like SQL injection and a host of other issues, but it could help mitigate a lot of XSS issues. Here are some links from the conversation:
http://www.gerv.net/security/content-restrictions/
http://weblogs.mozillazine.org/gerv/archives/007610.html
https://bugzilla.mozilla.org/show_bug.cgi?id=80713
There were some additional conversations I had with Netscape when they were coming out with the IE/Gecko rendering engine concept, which is a good one, but they still have it wrong, where they are making assumptions about what is safe, rather than giving the webmaster the granual control to protect their own users. It may be an academic excersize, because at the end of the day you can’t rely 100% on the browser community to fix this problem, but at the same time, they are the ones who invented most of these issues by increasing the flexibility of their platforms.
