Re: XHR security risks

On Thu, 08 Jun 2006 22:56:51 +1000, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> I'd like to pick up the discussion I started several weeks ago (see  
> <http://lists.w3.org/Archives/Public/public-webapi/2006Apr/0305.html>  
> and copy below)...
>
> In the meantime I've discussed the issue with Roy F., and we also talked  
> about it over on Mark Nottingham's blog (see  
> <http://www.mnot.net/blog/2006/04/20/form.submit>). I'm still convinced  
> that a user agent that allows an HTML page to submit an unsafe method  
> (such as POST, DELETE or PUT) without explicit user interaction is  
> buggy. This applies both to form.submit and XHR.

I don't see that it is buggy. However, there are obvious scenarios where  
it exposes a user to a potential security risk. If I put some magic into a  
browser that allows any HTML page from EvilOverlords.example.com to PUT or  
POST to any other page in example.com without explicit user interaction,  
it may be antisocial behaviour. If I allow those pages to PUT or POST to  
EvilOverlords.example.com from the user history I might be antisocial or I  
might be implementing some new and nasty company policy about checking  
everything employees do. But I don't see that it is ipso facto a bug.

There is a convention that you don't use GET for things with side effects,  
but there is nothing that enforces that convention. In an untrusted  
environment, it is possible to use GET for all kinds of badness too.  
(There are probably still people sending important financial transaction  
over unsecured HTTP via GET somewhere). I don't think the WebAPI specs are  
the place to try and enforce these kind of security policies, although the  
issues are worth noting in security sections for each spec.

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 13:42:16 UTC