- From: Ronan Oger <ronan@roasp.com>
- Date: Thu, 25 Nov 2004 10:08:49 +0000
- To: "Jim Ley" <jim@jibbering.com>
- Cc: www-svg@w3.org
On Wednesday 24 November 2004 21.48, you wrote: > ><ronan@roasp.com> wrote in message >news:39957.127.0.0.1.1101313599.squirrel@127.0.0.1... >> XSS does not pose a risk with respect to encoding tricks. Zero. None. If >> the encoding of a snippet is different, the parser will not recognize the >> wrongly encoded content and just return the litteral codes, causing the >> XSS trick to fail. > >This is incorrect, please read up on your CERT advisories, Bjoern's already >given a good example. > Jim, You're right. I should not claim XSS tricks are impossible. However, the encoding that matters and should override, according to RFC 3023 as far as I understand it is the one in the document. Hence, either the server-encoding is the encoding in the document, or the document encoding is already there. But in order for the document encoding to provide xss tricks, it has to be controlled by the parser and it has to be missed by the server to which the encoding was passed. The simplest security trick - parsing any inbound SVG documents - will catch this encoding trick. >> After all, there is no reason why SVG content would be exempt >> from the same due dilligence that HTML content requires to prevent xss >> exploits. > >It relies on the character encoding being known, this has already been >highlighted in the thread by Robin, whereby you have the server admins >requiring a charset parameter exactly because of XSS problems. > If the serverside people are doing their job, xss becomes very hard. This is because in order to do xss tricks, you not only need to trick the browser but you also need to trick the server into passing on the uploaded content. case 1: correct behaviour script elements are rejected. upload fails case 2: utf-16 encoding in xml preamble with encoded characters delimiting the script chunk. -same effect as case 1 case 3: utf-16 encoding in xml preamble not recognized by poorly-designed parser at server -uploaded xml rejected for being badly formed. case 4: no testing on server -script gets in unverified, and gets passed on to unsuspecting browser Here, there is some risk. 4.1: user browser attempts to parse utf-16 encoded svg thinking it is utf-8. parser encounters something like: a) <g>(/%*"รง&%+"*%+(/"%*(/+*(/+</g> and falls over during parsing. or like this: b) <text>+Z)("+/*=+)"*</text> which can cause a problem. where b) in utf-16 would mean (i did not bother to make a real example here) <text><script><![CDATA[ // JavaScript code here ]]></script> </text> OK then, what does this little exercise demonstrate? I think it demonstrates a need for the w3 to certify browser implementations as compliant, and that if this was in place, then we would not need to worry about this problem. It also demonstrates that we need a clear understanding of the order in which encoding has to be defined, and a clear understanding of what browsers fail to implement this order. Failing that, we just have to revert to the standard html rules. After all, if anybody were to *actually* listen to the CERT warnings, the internet would be long dead since they have been recommending nobody use IE, and that nobody a allow scripting on any but trusted sites... Maybe a short-term solution to all this would to simply ban character encoding in the svg preamble and to simply force it to be done on the server... Clearly difficult for people who don't control the server, but at least safe. And this problem is entirely a web problem, after all... Still, from my pragmatic point of view... SVG is simply stuck in the same rules as SGML: 1. Don't visit sites that have ecmascript that you do not trust unless you are willing to take chances 2. Don't allow users to upload content with ecmascript. Never. Under any circumstance. 3. Never, ever user-provided content from low-brow suppliers who accept SVG uploads and do not parse them serverside to verify they are safe. Now, getting off my high horse, I personally violate advice 1,2,3 daily. Ronan >Jim. > > > > > > > -- Ronan Oger http://www.roasp.com
Received on Thursday, 25 November 2004 10:05:41 UTC