W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: User confirmation and 307 redirects

From: Adam Barth <ietf@adambarth.com>
Date: Fri, 20 Aug 2010 10:41:40 -0700
Message-ID: <AANLkTimOjGAtSHXFRL0a1ct14Z8A40VebLmK747JYdGY@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>
On Fri, Aug 20, 2010 at 3:42 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> 1) For PUT and POST, just visiting any website on the planet with a mainstream browser in its default configuration can result in an automatic PUT or POST to any website on the planet. That's somewhat unfortunate, but it is a reality that at this point can't be changed. Trying to prevent this (or, worse yet, throwing up a confirmation dialog) only in the case where a redirect is involved is silly.

I believe that only works for POST.  HTML5 introduces the ability to
send PUT and DELETE via forms, but only back to the same-origin.  It
also explicitly blocks attempts to redirect these methods off-origin.

Roy, of course, would say that there are other HTTP user agents than
browsers.  :)

The way that I think makes sense to resolve this issue is as follows:

1) Remove the contrary-to-reality MUST NOT from the spec.
2) Add text (either inline in the definition of the redirects or in
the security considerations section) that explains the security
consequences of blindly following redirects with unsafe methods.

User agents can make up their own mind how they should mitigate those
threats.  Different user agents will make different decisions based on
a slew of factors, including what other functionality they expose
(e.g., that makes mitigating this threat pointless) or their usage
environment (e.g, not wanting to distract their users while driving
their cars).

Received on Friday, 20 August 2010 17:42:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:54 UTC