Re: Kathleen Moriarty's Discuss on draft-ietf-httpbis-rfc7238bis-02: (with DISCUSS)

On Feb 4, 2015, at 9:44 AM, Kathleen Moriarty wrote:

> Sure, my point is that this redirect can be exploited and that should
> be listed as a security consideration.  Can you take a look at the
> wording proposed by Barry and offer a suggestion that better explains
> the full security consideration, which is broader than just using TLS
> on the points of the session that get encrypted (load balancers, etc.
> may be a termination point)?  TLS doesn't fully mitigate this
> vulnerability, but helps with some level of mitigation.

I do not believe it is appropriate to say much more here, for the simple
reason that I don't want to describe every potential application security
vulnerability in every spec that extends HTTP.

What I would expect to see is a discussion of what additional security
concerns (beyond use of HTTP) are created by the addition of a 308 status
code.  In this case, due to the existing 301 status code, the only
additional security concern would be permanently redirecting the
destination of a POST form such that future POSTs of that same form
(beyond the immediate redirect) are sent directly to the redirect
target.  We used to have a paragraph that forbid automatically
redirecting unsafe requests, which was sufficient to cover this case,
but that was routinely ignored by browser developers.

It would be better to enhance RFC7231 to add a security consideration
on permanent redirects.  If you want to do that here, instead (or as
a prequel), I would point again to what authority means for HTTP
[RFC7230, sec. 9.1] and explain why the permanence of permanent redirects
ought to be treated with a level of skepticism inversely proportional to
how much trust the user has that the message is truly authoritative.
Use of TLS is one way of improving that trust, but does not prevent
misdirection from occurring due to untrusted content or shared
applications within the origin server.

In practice, people don't use permanent redirects to attack clients
because nobody browses untrusted sites with link-editing software,
cache poisoning is far more effective with a fake 200 response than
a fake redirect, and an attack on temporary redirects would be just as
effective (and more likely deployable).  Likewise, the distinction
between permanent and temporary redirects is really only significant
to a specific class of client (e.g., authoring tools).

This doesn't mean permanent redirects don't have a valuable meaning
in certain contexts, such as content management systems, or ought
to be disallowed because they can't always be trusted.  It is just
a gray scale of trust, like everything else on the Internet.

....Roy

Received on Thursday, 5 February 2015 00:09:07 UTC