- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 2 Mar 2006 09:18:15 -0800
- To: Chris Lilley <chris@w3.org>
- Cc: www-svg@w3.org, Jeff Schiller <codedread@gmail.com>
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. Regards, Maciej
Received on Thursday, 2 March 2006 17:18:15 UTC