Re: SVG 1.2 Comment: image/svg+xml;charset=''

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