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