Re: #328: user Intervention on Redirects

On 08.02.2012 05:38, Martin Thomson wrote:
> On 7 February 2012 08:07, Julian Reschke wrote:
>> The redirect might go to a resource that the user didn't ask to 
>> modify.
>
> I don't see the problem.  So I ask to modify X, but then X points me
> to Y, so I either automatically modify Y, or require confirmation
> before doing so.

The crux of the problem is that "or," you just wrote.

When redirect is allowed to be done always there is no "or,". With some 
potential for problems.
Anne appears to know of an application use-case that would jump head 
first into that usage if given half a chance.


>
> There isn't a security problem.  X has the information and could
> forward to Y itself.

Or Y could be hijacked temporarily and redirect to Z. Oops.
Or one of the other "open redirect" problems mentioned already.

>
> The only concern is over intent.  Whether the intent of the client
> extends to permitting a server to direct their request.
>
> I know that curl has a command line option for this behaviour, but it
> most clients don't have the luxury of millions of options.  So when
> you have to pick an option, choose the one that doesn't require a
> dialog box.
>
> Ultimately, this is between you and your client.  A specification
> shouldn't really need to say anything about (though we might make an
> exception for a security issue).

Indeed. We need to be clear that auto-redirect is an option that needs 
to be considered carefully first on a case-by-case basis, with a set of 
problems outlined, and if possible solutions to those problems pointed 
at. To me that seems to mean threat model texts and maybe a reference in 
the spec to that.

AYJ

Received on Tuesday, 7 February 2012 21:50:57 UTC