maluc and I got to talking today about a cross site scripting issue in Yahoo. It wasn’t exploitable as he showed it to me but after some testing we got it working. Click here in Internet Explorer to see the XSS popup on Yahoo. This is exactly what I was talking about the other day. Websites that allow you users to modify encoding methods are uniquely vulnerable.
Typically users don’t have access to modify meta data straight from the browser. Things like cookies, post strings, etc… However, as we all know they can be modified using things like proxies. Those things are known to be broken. What hasn’t sunk in yet is that allowing users to modify the context in which the page is rendered these websites are allowing attack vectors for those contexts. In this case Yahoo is vulnerable to US-ASCII encoding.
Typically this wouldn’t be a problem because they do a good job of output sanitation. However, because they haven’t accounted for every possibility in all the encoding methods out there, they are strangely vulnerable to something that doesn’t typically affect most websites. When I first wrote about this, I said that the main issue is for Tomcat or if for some reason the user was allowed to specify the encoding method. Well before I ever saw an actual vulnerable page (other than in the lab) it was already clear that you cannot allow encoding methods to be switched on the fly.
It’s almost a hidden universe inside web application security. If you never know to check for it you will fall victim to it. It’s difficult to stop this without ensuring that you not vulnerable to anything in any encoding method. I know we haven’t found all the issues out there, so until we do, allowing users to switch encoding methods is a bad proposition. Thanks to maluc for this one!