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