Re: User confirmation and 307 redirects

On Aug 19, 2010, at 2:37 PM, Roy T. Fielding wrote:

> On Aug 19, 2010, at 2:10 PM, Adam Barth wrote:
> 
>> On Thu, Aug 19, 2010 at 2:06 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> It isn't a feature.  It is a security constraint.  The fact that some
>>> browsers have security holes is well known.
>> 
>> It's completely ineffective as a security mechanism.  At best, all it
>> could do is result in blame-the-user security, which isn't security at
>> all.
> 
> Please think about it for a while before you try to convince me that a
> DELETE on any website on the planet should be able to result in an automatic
> DELETE being redirected to any other website on the planet, or your
> local intranet.  Likewise for PUT, POST, etc.

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.

In the case of DELETE, this can't be done with mainstream browsers, since the only ways available to produce a DELETE request do not transparently

2) I note also that the requirement as stated applies even to the same-site case. In what way is a security mechanism then? 

3) Most browsers in their default configurations will not show the user where a form submission will go or what HTTP method it will use before the user hits the submit button. The form could have submitted a POST to a "bad" place in the first place. Why require user confirmation only in the case where an HTTP redirect happened, since the user did not know where his or her form was going in the first place?

> 
> There is no compelling need for auto-redirect for an unsafe method.
> If you can't figure out a safe way that your "user" (an entity which
> varies substantially based on the type of HTTP client being used)
> can approve of the redirect, then the safe choice is to not redirect
> the request.

Generally, "always fail" is a stronger security mechanism than "prompt the user". However, in this case, it's still ineffective in the context of a browser, since there are so many other ways to maliciously POST to a URI that wasn't chosen by the user. You don't even have to use script to do it.

>  Your concerns about the ugliness of such a dialog are
> not relevant to the requirement as written in the spec, and it simply
> wouldn't matter if every single browser implemented it wrong:
> browsers make up only a small percentage of HTTP client vendors.

Are there categories of HTTP clients that generally do follow this requirement, other than via an assumption that their "user" is someone other than the end-user, or that their end-user has given blanket confirmation?

Regards,
Maciej

Received on Friday, 20 August 2010 10:43:25 UTC