Subject: #328: user Intervention on Redirects

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Feb 2012 10:55:33 +1100

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238>

> The redirect status codes define requirements for user intervention; e.g.,
> 
> If the 301 status code is received in response to a request method that is known to be "safe", as defined in Section 7.1.1, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
> 
> However, this requirement is not often implemented by UAs.

I'm now wondering if we should consider removing this requirement altogether.

The way it's structured now, the requirement associates intent with a URI, when in reality intent is associated with the UI; the user is blissfully unaware of the actual resource being manipulated.

More to the point, there's little to no difference between an HTML form POSTing somewhere and getting redirected somewhere else to the form just using the second URI in the first place.

I think this requirement is well-intentioned, but the threat model of the Web has changed significantly since it was written.

Thoughts?

--
Mark Nottingham   http://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Feb 2012 16:10:00 -0800

> I'm now wondering if we should consider removing this requirement altogether.

Remove it.  I imagine that the original idea was that you might want
to prevent a server that from getting you to pass your secrets to some
other server.  Or that it might do a bait and switch.

In a world with clickjacking, this sort of measure just seems naive.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Feb 2012 17:12:00 +1300

On 7/02/2012 1:10 p.m., Martin Thomson wrote:
> On 6 February 2012 15:55, Mark Nottingham wrote:

Clickjacking as a whole is still very much relevant to this redirection 
capability.
BUT, given that the client UA is where the redirect is done anyway makes 
little sense to prohibit it entirely.

IMO move it from the protocol spec to the security threat model as 
instruction that UA should take care before following redirects 
automatically.

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Feb 2012 16:14:43 +0100

> I think this requirement is well-intentioned, but the threat model of the Web has changed significantly since it was written.

1) Remove the statements from 301/302/307.

2) In a single place, explain the risks of automatically redirecting 
when the new request method is unsafe. Note this applies to *any* kind 
of following redirects, including future ones (such as 308).

Not sure about where to put the text for 2); does this belong into the 
description of 3xx or into the Security Considerations?

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 07 Feb 2012 16:49:08 +0100

> description of 3xx or into the Security Considerations?

Can you explain to me the scenario for 2? In particular how a redirect  
makes this more dangerous than just performing the request directly.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Feb 2012 17:07:59 +0100

On 2012-02-07 16:49, Anne van Kesteren wrote:
> On Tue, 07 Feb 2012 16:14:43 +0100, Julian Reschke
> <[email-masked]> wrote:

The redirect might go to a resource that the user didn't ask to modify.

Consider an XHR PUT being redirected to a different server, or to a 
different resource on the same server.

Yes, unsafe requests are ... unsafe, and thus need to be executed 
carefully. This consideration is about clients that follow the redirect 
automatically, and don't leave the control to whoever initiated the request.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Feb 2012 08:38:04 -0800

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

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

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

--Martin

---

From: Chris Weber <[email-masked]>
Date: Tue, 07 Feb 2012 09:10:42 -0800

On 2/7/2012 8:38 AM, Martin Thomson wrote:
> 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. There isn't a security problem. X has the information and
> could forward to Y itself. 

Within the security community the issue has been termed "Open Redirect"
and has been well documented here
http://cwe.mitre.org/data/definitions/601.html and here
https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
as well as other places.  It's not a vulnerability by itself but has
been heavily abused by phishing attacks over the years.  As such, any
security review or penetration test performed today will flag open
redirects as an issue that needs to be addressed.  To protect their
users, many top applications have built in 'safe redirect' protections
that allow same-origin redirects and either disallow or prompt the user
before allowing redirection to third-party domains. 

>From my point of view it's the job of the applications to implement safe
redirection protection, and several libraries already exist for this. 
If users started seeing prompts for all offsite redirects I'm sure that
they'd just end up clicking the check box to 'never show me this message
again.'

Best regards,
Chris Weber

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Feb 2012 18:21:54 +0100

On 2012-02-07 18:10, Chris Weber wrote:
 > ...

Clarifying: "Open" means that the target of the redirect actually 
depends on something the request contains, such as a query parameter, right?

---

From: Chris Weber <[email-masked]>
Date: Tue, 07 Feb 2012 09:35:49 -0800

> depends on something the request contains, such as a query parameter,

True, that's the most common case.  An example would be -
http://www.example.com/redir?target=http://foo.bar - where the query
parameter named 'target' has a user-controlled value which gets used
(most commonly) in an HTTP 302 redirect's 'Location' header.

---- REQUEST ----

GET /redir?target=http://foo.bar HTTP/1.1
Host: www.example.com

---- RESPONSE ----

HTTP/1.1 302 Found
Location: http://foo.bar/

-CW

---

From: Adam Barth <[email-masked]>
Date: Tue, 7 Feb 2012 10:59:47 -0800

Open redirectors usually use GET requests rather than unsafe methods.

Adam

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Feb 2012 11:25:42 -0800

It's not so much the issue of having an open redirect, it more relates
to the way that the browser assigns some level of trust to the server
when following the redirect.  Worse, the target server assigns a
degree of trust to the client when accepting the new request.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Feb 2012 21:15:41 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238>

(changed subject line accordingly)

> I think this requirement is well-intentioned, but the threat model of the Web has changed significantly since it was written.

Here's a proposal that removes the normative requirement, refactors the 
text to say things only once, but keeps a warning.

In the 3xx Introduction, say:

    Note that for methods not known to be "safe", as defined in
    Section 6.1.1, automatic redirection needs to done with care, since
    the redirect might change the conditions under which the request was
    issued.

In the description for 301 remove:

    If the 301 status code is received in response to a request method
    that is known to be "safe", as defined in Section 6.1.1, then the
    request MAY be automatically redirected by the user agent without
    confirmation.  Otherwise, the user agent MUST NOT automatically
    redirect the request unless it can be confirmed by the user, since
    this might change the conditions under which the request was issued.

dito for 302 and 307.

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/238/238.diff>

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 7 Feb 2012 12:51:18 -0800

On Tue, Feb 7, 2012 at 12:15 PM, Julian Reschke <[email-masked]> wrote:
>>> If the 301 status code is received in response to a request method that
>>> is known to be "safe", as defined in Section 7.1.1, then the request MAY be
>>> automatically redirected by the user agent without confirmation. Otherwise,
>>> the user agent MUST NOT automatically redirect the request unless it can be
>>> confirmed by the user, since this might change the conditions under which
>>> the request was issued.
>>>
>> The way it's structured now, the requirement associates intent with a URI,
>> when in reality intent is associated with the UI; the user is blissfully
>> unaware of the actual resource being manipulated.
>>
>> More to the point, there's little to no difference between an HTML form
>> POSTing somewhere and getting redirected somewhere else to the form just
>> using the second URI in the first place.
>>
>> I think this requirement is well-intentioned, but the threat model of the
>> Web has changed significantly since it was written.
>>
>> Thoughts?
>> ...
>
>
> Here's a proposal that removes the normative requirement, refactors the text
> to say things only once, but keeps a warning.
>

+1

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Feb 2012 07:47:19 +1100

+1

On 08/02/2012, at 7:15 AM, Julian Reschke wrote:

> Here's a proposal that removes the normative requirement, refactors the text to say things only once, but keeps a warning.
> 
> Proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/238/238.diff>
> 
> Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Feb 2012 13:06:39 -0800

>>   the redirect might change the conditions under which the request was

Good.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 08 Feb 2012 10:47:32 +1300

On 08.02.2012 05:38, Martin Thomson wrote:
> On 7 February 2012 08:07, Julian Reschke wrote:

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

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

> 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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Feb 2012 14:09:00 -0800

> When redirect is allowed to be done always there is no "or,". With some

Right. I hate "or".

I'd rather not have the point of flexibility, but am willing to live
with it (hence my response to Julian's suggestion - it's a definite
improvement on the text, though not the substance).

On the other hand, if all clients followed redirects, safe method or
not, then we at least have something we can build on.  Right now, the
uncertainty means that you can't rely on any particular behaviour at
all.  That imposes a constraint that I don't like very much.

> Anne appears to know of an application use-case that would jump head first
> into that usage if given half a chance.

I have one too. It relies on a permanent redirect for unsafe methods.
Crazy, but far more elegant than any alternatives.

> Or one of the other "open redirect" problems mentioned already.

Open redirects are not the problem.  They are "a" problem, but
requiring one behaviour or the other here isn't going to fix the open
redirect problem unless you wanted to stop automatic follows for safe
methods as well...or you had some sort of magic fairy wand that made
all resources in existence safe for safe requests.

--Martin

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Feb 2012 09:29:48 +0100

On 2012-02-07 22:06, Martin Thomson wrote:
> On 7 February 2012 12:51, Adam Barth<[email-masked]>  wrote:

Thanks for all the feedback! Applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1534>.

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 16 Feb 2012 07:58:00 +0100

> There isn't a security problem.  X has the information and could

No it doesn't. Y may require authentication / session cookies / IP based
access lists etc which X can not provide on it's own.

Obviously it only makes a significant difference for user-agents using
explicit URLs and not in the fuzzy case of surfing some web site with a
browser.

Regards
Henrik

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 Feb 2012 15:08:40 -0800

> access lists etc which X can not provide on it's own.

Damn, I can be dense sometimes.  Obviously, if I can convince you to
send me a POST that says "transfer $10 to acct number X" (which is
trivially easy) and then redirect you to your bank, if you have an
open session and the bank doesn't check Referer (though that wouldn't
necessarily help), you've just made an easy $10.

Are there any measures that browsers could take to limit this sort of
thing?  I'm thinking for Julian's 308 draft in particular.  Obviously
it already applies to 307.  The 308 draft only cites Section 11 of p2,
which doesn't even mention this particular problem.

Just off the cuff, it seems to me that a method preserving redirect
(307, 308) should almost operate in the same sort of security context
as a cross domain request (CORS).  That means that user credentials
are removed unless the target resource explicitly accepts them.  Or
you could just take the position that this is a problem for the target
site.

Problem?  Or have I just missed something else?

---

From: Adam Barth <[email-masked]>
Date: Fri, 17 Feb 2012 15:19:33 -0800

2012/2/17 Martin Thomson <[email-masked]>:
> thing?

You're describing a CSRF attack.  There is a moderate size literature
about possible browser solutions to CSRF, but none of them have caught
on.  In the meantime, web site defend themselves against this attack
using secret tokens.

For more details, please see
<http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf>.

Adam

---

From: Henrik Nordström <[email-masked]>
Date: Sat, 18 Feb 2012 16:51:14 +0100

> necessarily help), you've just made an easy $10.

Yes.

> Are there any measures that browsers could take to limit this sort of

Yes, and they do to various degree.

> you could just take the position that this is a problem for the target

It's a problem for all involved.

user-agent should limit the exposure of automatic cross-domain actions
other than GET.

Non-safe methods (i.e. mostly anything except for HEAD/GET) should not
be automatically retried on redirect.

Origin servers with user-sensitive actions performed via POST need to
use embedded session parameters to protect from cross-domain actions
(i.e. embedded one-time parameter in forms to verify the origin of the
submitting form)

Regards
Henrik