Re: SVG 1.2 Tiny: Networking API issues

On Mar 2, 2006, at 10:14 PM, Chris Lilley wrote:

> On Thursday, March 2, 2006, 6:18:15 PM, Maciej wrote:
>
> MS> 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,[...]
>
> I encourage you to re-read this part.

I think there are 0 different security models that could safely be  
used by a browser-hosted implementation of SVG that includes Connection.

> MS> As mentioned before on this list, this model is insufficient for a
> MS> raw socket API that is offered to arbitrary web content.
>
> MS> (1) The real restriction used by web browsers is not just host,  
> but
> MS> host+port +scheme. (2)
>
> Yes, that would be another example. It does of course allow access  
> to a
> range of other protocols, especially when used with a widely tunnelled
> port such as 80.

You took my remarks out of context. I was explaining reasons why your  
proposed security model that a web browser might use would not in  
fact be secure. The fact that browsers are more restrictive than your  
proposed model for access methods other than Connection is one piece  
of supporting evidence for why your proposed model won't work. But I  
also mentioned in my point (2), which you omitted, that raw socket  
access has additional security issues that even the narrower browser  
access control model would not address.

You attempted to dismiss Jeff's security concerns, but in fact  
security concerns about Connection are entirely valid. Your suggested  
model for web browsers is not Safe.

> MS> I think it is unwise to specify networking APIs for the web  
> without
> MS> properly addressing the security considerations.
>
> So on the one hand you list an additional security model,  
> demonstrating
> the point that there are a variety of models that may be used  
> depending
> on circumstance; and on the other hand you seem to want one specific
> security model to be mandated?

Please don't put words in my mouth. I did not ask to mandata a  
security model. Nor did I list an "additional" security model. Your  
proposed model does not work, and my point (1) was not intended to  
state a model that works, but rather to illustrate flaws in your model.

Regards,
Maciej

Received on Friday, 3 March 2006 20:01:06 UTC