W3C home > Mailing lists > Public > www-svg@w3.org > March 2006

Re: SVG 1.2 Tiny: Networking API issues

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 2 Mar 2006 09:18:15 -0800
Message-Id: <C0475B9C-2332-41F7-9267-7B7AE4F69C38@apple.com>
Cc: www-svg@w3.org, Jeff Schiller <codedread@gmail.com>
To: Chris Lilley <chris@w3.org>

On Mar 2, 2006, at 6:39 AM, Chris Lilley wrote:

> Hello www-svg,
> Jeff Schiller <codedread@gmail.com> wrote:
>> I'm no security expert, but what about a script that requests a
>> connection to the localhost on various ports (i.e. FTP 21, etc) and
>> sniffs about the local host, then sends the data it finds back to the
>> server through standard ports? Would that effectively open up your
>> computer by bypassing any firewall since the "attack" would come from
>> within the localhost browser or do firewalls watch for that sort of
>> thing too?
> There are a number of different security models that might be used by
> different types of svg implementations. For example, a closed
> implementation used as a user interface, which cannot accept arbitrary
> content, might have one set of requirements. A military application
> might have different requirements.
> In web browsers, a common model is to prohibit cross-domain
> communication. So if the content was loaded from some domain X, it can
> only talk to X. Localhost is a different domain under that model.

As mentioned before on this list, this model is insufficient for a  
raw socket API that is offered to arbitrary web content. (1) The real  
restriction used by web browsers is not just host, but host+port 
+scheme. (2) Even a raw socket connection to http is not safe because  
custom headers allow you to access content you couldn't otherwise,  
for instance the "Host:" header can let you get to a different server  
on a virtual host.

Connection is not safe for use on the web as specified, it can only  
be safely offered to special "trusted" content, and it seems like  
features of this nature are out of scope for the W3C.

I think it is unwise to specify networking APIs for the web without  
properly addressing the security considerations.

Received on Thursday, 2 March 2006 17:18:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:07 UTC