Re: SVG 1.2 Tiny: Networking API issues

On Friday, March 3, 2006, 9:01:03 PM, Maciej wrote:


MS> 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.

MS> I think there are 0 different security models that could safely be  
MS> 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.

MS> You took my remarks out of context. I was explaining reasons why your  
MS> proposed security model 

I don't propose a model

MS> that a web browser might use would not in  
MS> fact be secure. The fact that browsers are more restrictive than your  
MS> proposed model for access methods other than Connection is one piece 
MS> of supporting evidence for why your proposed model 

I don't propose a model

MS> won't work. But I  
MS> also mentioned in my point (2), which you omitted, that raw socket  
MS> access has additional security issues that even the narrower browser  
MS> access control model would not address.

MS> You attempted to dismiss Jeff's security concerns, 

No, I attempted to discuss them with a range of example security models while being very clear that none of these models was mandated.

MS> but in fact  
MS> security concerns about Connection are entirely valid. Your suggested  
MS> model 

I don't suggest using a particular a model

MS> 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?

MS> Please don't put words in my mouth. I did not ask to mandata a  
MS> security model. Nor did I list an "additional" security model. Your 
MS> proposed model does not work,

I am not trying to put words in your mouth. However, on that note, please be aware that I am explicitly not proposing a security model - either one model, or a list of allowd models.Your multiple references to "my proposed" model are, therefore, assigning to me a position that I have not taken. (Or putting words into my mouth, if you like).

 
MS>  and my point (1) was not intended to  
MS> state a model that works, but rather to illustrate flaws in your model.

Since I don't propose a model, security being an orthogonal aspect, its not clear how you can find flaws in it.








-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Saturday, 4 March 2006 12:21:46 UTC