Re: [OAUTH-WG] New header "Fragment-Scope" to prevent assertions leakage through redirects

I would also be interested to know about the possible response headers for
referrer (a draft?). Last time we brainstormed the problem with Brad Hill
we thought it could break something with search engines flow and referrer
policy.

> I have tried to document the response headers that can help stop leaking
referrer.

On Fri, Apr 10, 2015 at 4:08 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> Thanks,
>
> I have tried to document the response headers that can help stop leaking
> referrer.
>
> Being able to do the same thing to stop fragment leaking would be a good
> thing.
>
> If the W3C adds that then I would add it to our recommendations.
>
> In the Interim without browser support we may need to look at other
> methods to pass tokens to clients in the browser.
>
> I am certainly interested in tracking your proposal.
>
> John B.
>
> On Apr 10, 2015, at 4:00 PM, isciurus <isciurus@gmail.com> wrote:
>
> Hi,
>
> One of the recent drafts
> https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html was
> brought to my attention. Regarding the part "2.2. Security Compromise: The
> Authorization Server As Open Redirector":
>
>     The legitimate OAuth Authorization response will include an access
> token in the URI fragment.
>     Most web browsers will append the fragment to the URI sent in the
> location header of a 302 response if no fragment is included in the
> location URI.
>
> This browser behaviour with a url fragment reattaching is indeed used
> widely in attacks on OAuth (for example, one of the recent on the bitcoin
> exchange
> http://sakurity.com/blog/2015/01/10/hacking-bitcoin-exchanger.html) and I
> am also aware of one attack on OpenID 2 implementation leaking a valid
> signature using the same technique.
> We are trying to propose a browser-level protection from sensitive url
> fragment data reattach on cross-domain redirects:
> http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0066.html
> A new header in the AS response would also block fragment reattach in the
> following scenario:
>
>   https://AUTHORIZATION_SERVER/authorize?response_type=token
> <https://authorization_server/authorize?response_type=token>
>   &client_id=good-client&scope=VALID_SCOPE
>   &redirect_uri=https%3A%2F%2AUTHORIZATION_SERVER%Fauthorize
>   %3Fresponse_type%3Dcode
>   %26client_id%3Dattacker-client-id
>   %26scope%3DINVALID_SCOPE
>   %26redirect_uri%3Dhttps%253A%252F%252Fattacker.com
>
> But it would additionally block exploitation of vulnerable clients which
> have open redirects on their domains and don't whitelist their redirect_uri:
>
>   https://AUTHORIZATION_SERVER/authorize?response_type=token
> <https://authorization_server/authorize?response_type=token>
>   &client_id=good-client&scope=VALID_SCOPE
>   &redirect_uri=https%3A%2F%2good-client.com%Fopen_redirect
>   %3Furl%3Dhttps%253A%252F%252Fattacker.com
>
> This can improve the situation with already deployed clients in large
> scale. Let me know if this proposal is interesting to the OAuth WG.
>
> Thanks,
> Andrey
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>