4 ms·

Can anyone explain how the browser can make a site unsafe? I thought rule #1 was "don't trust the client".

tptacek 17y ago
For instance, by filtering and transforming metacharacters in such a way that it accidentally picks up neutral metacharacters turns them into hostile metacharacters. Some sites, especially complicated ones, have intricate rules for what, where, and how metacharacters are quoted, substituted for entities, or rejected. It probably isn't a great idea to interfere with them.
dasil003 17y ago
XSS is not about the server trusting the client, it's the other way around. XSS exploits the trust that a user has of a website. It is the site's responsibility to prevent XSS by preventing any user from injecting executable code into the HTML, because if they can do that on a public page then they can write code that sends the private credentials of all users who visit that page anywhere they want. Preventing XSS is tricky because of the inability to sandbox user-generated content. Everything in a page has the same security level. This means if you allow user generated content you need to be aware of all the ways that all the browsers can trigger code execution. There are numerous tags, attributes, CSS selectors, and url protocols that can trigger executable javascript code, and on top of that there are layers of internal translation in the browser and parsed content such as HTML entities, escaped unicode and other internal browser transformations. So what Microsoft has done, is to attempt to magically determine–without any context–what code patterns look like they were probably submitted by a malicious party, and then perform some opaque transformation to "prevent" the vulnerability. In the process they will undoubtedly break legitimate code, and make the job of preventing XSS more difficult because there is yet another transformation that one browser does differently from the rest. To answer your question, what IE8 has apparently been found to do is translate some non-executable code form into something that is executable, thus rendering something that previously would have been a safe sanitization method across all known browsers into something that is exploitable in the latest version of IE. Sure it's unintentional, but the whole approach is braindead. If Microsoft wants to further the state of web security they need to pursue a real security model such as real sandboxing of HTML documents, since all it takes is one obfuscated hack in IE8 magic security model to render it useless and more difficult to secure since some percentage of people will never upgrade.
qeorge 17y ago
This is my understanding of the problem, but I'm not a security guy so please correct me where I'm wrong. The rub is that IE8 modifies the source of a page to prevent XSS attacks. Essentially it escapes a bunch of strings, like <script> tags. Sanitization like this is common to sites which allow UGC, with the onus being on the programmer to perform the sanitization. Unfortunately, a lot of popular UGC sites either attempt no sanitization, or screw it up (e.g., Twitter, MySpace). Thus, IE8 attempts basic sanitization of all pages automatically, unless a header is sent telling it not to. In theory, this should provide basic protection for the user when the site's developers drop the ball. Long story short, there is an error in their sanitization routine. Thus, an attacker can pass a seemingly harmless string (which would not be filtered by the application's own security), which is then escaped by IE8, producing malicious output. This type of bug is somewhat common, but since many dev's are rolling their own sanitization routines (bad idea [1]), the exposure is usually limited to one site. But because IE8's filter runs on all sites, any site which contains the malicious string is affected. Given the huge number of sites that allow some kind of UGC, this is a huge problem. Reddit's recent worm is somewhat analogous, in that its a case of a well-intentioned sanitization method being exploited. Their post mortem illuminates what a complex problem this is: http://blog.reddit.com/2009/09/we-had-some-bugs-and-it-hurt-us.html http://blog.reddit.com/2009/09/we-had-some-bugs-and-it-hurt-... Hope that was helpful. [1] Note: In a similar vein, Mr. Ptacek and Mr. Lawson have decried rolling your own cryptography solution, and instead advocate using a battle tested solution like Keyczar. This is great advice, and should also be applied to sanitization methods.

For instance, by filtering and transforming metacharacters in such a way that it accidentally picks up neutral metacharacters turns them into hostile metacharacters. Some sites, especially complicated ones, have intricate rules for what, where, and how metacharacters are quoted, substituted for entities, or rejected. It probably isn't a great idea to interfere with them.

dasil003 17y ago

XSS is not about the server trusting the client, it's the other way around. XSS exploits the trust that a user has of a website. It is the site's responsibility to prevent XSS by preventing any user from injecting executable code into the HTML, because if they can do that on a public page then they can write code that sends the private credentials of all users who visit that page anywhere they want. Preventing XSS is tricky because of the inability to sandbox user-generated content. Everything in a page has the same security level. This means if you allow user generated content you need to be aware of all the ways that all the browsers can trigger code execution. There are numerous tags, attributes, CSS selectors, and url protocols that can trigger executable javascript code, and on top of that there are layers of internal translation in the browser and parsed content such as HTML entities, escaped unicode and other internal browser transformations. So what Microsoft has done, is to attempt to magically determine–without any context–what code patterns look like they were probably submitted by a malicious party, and then perform some opaque transformation to "prevent" the vulnerability. In the process they will undoubtedly break legitimate code, and make the job of preventing XSS more difficult because there is yet another transformation that one browser does differently from the rest. To answer your question, what IE8 has apparently been found to do is translate some non-executable code form into something that is executable, thus rendering something that previously would have been a safe sanitization method across all known browsers into something that is exploitable in the latest version of IE. Sure it's unintentional, but the whole approach is braindead. If Microsoft wants to further the state of web security they need to pursue a real security model such as real sandboxing of HTML documents, since all it takes is one obfuscated hack in IE8 magic security model to render it useless and more difficult to secure since some percentage of people will never upgrade.

qeorge 17y ago

This is my understanding of the problem, but I'm not a security guy so please correct me where I'm wrong. The rub is that IE8 modifies the source of a page to prevent XSS attacks. Essentially it escapes a bunch of strings, like <script> tags. Sanitization like this is common to sites which allow UGC, with the onus being on the programmer to perform the sanitization. Unfortunately, a lot of popular UGC sites either attempt no sanitization, or screw it up (e.g., Twitter, MySpace). Thus, IE8 attempts basic sanitization of all pages automatically, unless a header is sent telling it not to. In theory, this should provide basic protection for the user when the site's developers drop the ball. Long story short, there is an error in their sanitization routine. Thus, an attacker can pass a seemingly harmless string (which would not be filtered by the application's own security), which is then escaped by IE8, producing malicious output. This type of bug is somewhat common, but since many dev's are rolling their own sanitization routines (bad idea [1]), the exposure is usually limited to one site. But because IE8's filter runs on all sites, any site which contains the malicious string is affected. Given the huge number of sites that allow some kind of UGC, this is a huge problem. Reddit's recent worm is somewhat analogous, in that its a case of a well-intentioned sanitization method being exploited. Their post mortem illuminates what a complex problem this is: http://blog.reddit.com/2009/09/we-had-some-bugs-and-it-hurt-us.html http://blog.reddit.com/2009/09/we-had-some-bugs-and-it-hurt-... Hope that was helpful. [1] Note: In a similar vein, Mr. Ptacek and Mr. Lawson have decried rolling your own cryptography solution, and instead advocate using a battle tested solution like Keyczar. This is great advice, and should also be applied to sanitization methods.