Charles McCathieNevile schrieb:
On Thu, 08 Jun 2006 22:56:51 +1000, Julian Reschke
<[EMAIL PROTECTED]> 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
