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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
