Re: New header for "Fragment-Scope"?

On Jan 9, 2015, at 11:56 AM, Mark Nottingham wrote:

> Brad Hill brought up an interesting proposal on the repo (I closed the issue as it was in the wrong place).
> 
> —8<---
> 
> A recurring weakness with OAuth and related capability URL usages (http://www.w3.org/TR/capability-urls/) is the reapplication of URL fragments on redirects:
> 
> http://tools.ietf.org/html/rfc7231#section-9.5
> 
> This behavior is frequently abused in combination with resources that act as open redirectors to leak sensitive information in a fragment.
> 
> I would like to suggest an additional header, 'Fragment-Scope' that could be sent with a Location header on a 3xx to control the disposition of a fragment after a redirect. Values would be 'no-redirect' which would instruct the user agent to discard the fragment on any subsequent redirect, or 'same-origin' which would discard the fragment after any non-same-origin redirect. The scope rule, once set, would remain until the user agent terminates following redirects. (so a 'same-origin' policy could not be stripped by redirecting to a second open-redirector in the same origin, and then off-origin from there).
> 
> —>8—
> 
> What do people think?

I think it has nothing to do with HTTP.  The request invocation engine
(e.g., browser) is responsible for determining whether the original
fragment applies after the request, regardless of zero or more redirects.
What they should do is tell the fetch algorithm to discard the fragment
prior to performing retrieval, or at least prior to following a redirect.
That is an internal implementation concern.

Regardless, adding more bits for new clients won't fix the leak of 
"sensitive" information on deployed clients. I don't think adding more
hacks to an already hacked notion of capability URLs is a worthwhile effort.

....Roy

Received on Friday, 9 January 2015 20:34:12 UTC