Re: New header for "Fragment-Scope"?

> > 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 ( is the reapplication of URL
fragments on redirects:
> >
> >
> >
> > 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
> ....Roy

The nice part is that it can potentially fix the deployed clients as well,
since the behavior is defined on provider side. I have not seen any cases
where client would legitimately need to make chained redirects with a
token/signature to another origin preserving Fragment.


Received on Wednesday, 14 January 2015 08:10:33 UTC