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

>
> * Chris Lilley wrote:
>>Can you explain the XSS attack and charset in more detail? What is the
>>attack, does a default charset actually help prevent it or is that
>>mythology, how should people actually guard against such attacks.
>
> See for example
>
>   * http://www.cert.org/advisories/CA-2000-02.html
>   * http://www.cert.org/tech_tips/malicious_code_mitigation.html
>
> If a web site allows to insert foreign code, you might be able to inject
> specific octet sequences that affect encoding detection heuristics, for
> example, injecting Bj+APY-rn might cause Internet Explorer to consider
> the document UTF-7 encoded; if you inject +ADw-script+AD4... you can by-
> pass code that attempts to filter script elements or escape all < chars
> or makes similar attempts to protect against such attacks.

I, like many on this list,  have been preventing XSS exploits since the
90's. THe problem dates back to the creation of javascript.

The specter of xss for SVG is the same as it is for HTML. It stems from
scripting and is limited to instances where the user is allowed to submit
form fields which contain script snippets.

Tricks with poorly formed content do not apply to XML, which is much
stricter than sgml. This is really not a problem any more as the parsers
simply reject malformed content.

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.

Granted, XSS risk exist with escaped characters within scripting. This is
why we never allow scripting content of any kind in user-contributed
content in portals. Recognizing script elements is tricky, but well
established. 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.

Ronan

Received on Wednesday, 24 November 2004 16:26:44 UTC