W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: New header for "Fragment-Scope"?

From: isciurus <isciurus@gmail.com>
Date: Sat, 10 Jan 2015 01:18:00 +0000
Message-ID: <CAAJG_r-LvnS7J_TzdFUd7hEaDPdpUx628VbG4xgjA8Xcg8Agqg@mail.gmail.com>
To: ietf-http-wg@w3.org
> > 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

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC