Re: XHR security risks

On Thu, 08 Jun 2006 23:54:53 +1000, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> ... it exposes users to a potential security risk, and there's nothing  
> the user can do about it except disabling scripting. I think that is a  
> problem.

SURE. That doesn't make it a bug per se. It also exposes the user to a  
bunch of functionality that they might appreciate. I thnk it's a decision  
to implement or not that way, and to use a user agent that does that or  
not. I would be surprised if desktop browsers for general release were so  
permissive. But there are a wider range of user agents and use cases, even  
among the manufacturers of desktop browsers.

> RFC2616 calls it a convention, but also says
>
...
>
> Naturally, it is not possible to ensure that the server does not  
> generate side-effects as a result of performing a GET request; in fact,  
> some dynamic resources consider that a feature. The important  
> distinction here is that the user did not request the side-effects, so  
> therefore cannot be held accountable for them.'

To the extent that RFC 2616 determines who is held accountable this is  
true. But real use cases go far beyond the reach of RFCs.

> If a server implements unsafe actions upon GET, that's a bug in the  
> server. For instance, should a GET request to a certain URL cause a  
> vendor to ship something to me (just because my user agent pre-caches  
> content linked from the current page), it's the vendor's problem, not  
> mine.

Assuming the vendor accepts RFC2616 as binding. If not, and the vendor has  
your money, you know about possession being 9/10 and all that...

My basic position is that all these things should be noted for  
information, because they are real implementation and use issues, that  
affect interoperability of code in particular. But the spec should not say  
which things are allowed or not based on our notion of appropriate  
security - since implementors will ignore us if they decide they want to,  
and we should not be randomly closing off things that have use cases  
because we decide that some bad use case can be made too. In the first  
instance that is the job of implementors, in the second it is a seperate  
effort in standardisation which is somewhat orthogonal to our work of  
specifyig the APIs that people use.

cheers

Chaals

-- 
Charles McCathieNevile                     chaals@opera.com
   hablo español  -  je parle français  -  jeg lærer norsk
      Peek into the kitchen: http://snapshot.opera.com/

Received on Thursday, 8 June 2006 14:37:40 UTC