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

From: isciurus <[email-masked]>
Date: Fri, 10 Apr 2015 16:00:52 -0700

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

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Apr 2015 16:08:21 -0700

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-masked]> 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>
> 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>
>   &redirect_uri=https%3A%2F%2good-client.com <http://2good-client.com/>%Fopen_redirect
> 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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: isciurus <[email-masked]>
Date: Fri, 10 Apr 2015 16:37:24 -0700

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.

On Fri, Apr 10, 2015 at 4:08 PM, John Bradley <[email-masked]> wrote:

> In the Interim without browser support we may need to look at other
> methods to pass tokens to clients in the browser.
>
> 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.
> <https://authorization_server/authorize?response_type=token>
> <https://authorization_server/authorize?response_type=token>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Apr 2015 08:28:06 -0600

I'm hardly speaking with any authority here but my hope/expectation is that
using Origin Only for the Referrer Policy would provide enough info in the
referer (the origin) so as to not break search engines flows or other
analytics that are using data from the referer header. The referring domain
is provided, which is useful data, but without there query or path that
often leaks sensitive data or tokens.

https://w3c.github.io/webappsec/specs/referrer-policy/ or
http://www.w3.org/TR/referrer-policy/ is the work in progress on Referrer
Policy.

On Fri, Apr 10, 2015 at 5:37 PM, isciurus <[email-masked]> wrote:

>> 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":
>>
>> 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