Re: XHR security risks

Charles McCathieNevile schrieb:
> 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 

Well, 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.

> 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 

RFC2616 calls it a convention, but also says

'In particular, the convention has been established that the GET and 
HEAD methods SHOULD NOT have the significance of taking an action other 
than retrieval. These methods ought to be considered "safe".'

Note it goes on saying

'This allows user agents to represent other methods, such as POST, PUT 
and DELETE, in a special way, so that the user is made aware of the fact 
that a possibly unsafe action is being requested.

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

(Emphasis on the first sentence above)

(see <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>).


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

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.

Best regards, Julian

Received on Thursday, 8 June 2006 13:55:04 UTC