Re: [OAUTH-WG] State Leakage Attack

[tors...@lodderstedt.net]

Hi Daniel,

how is the attackers supposed to utilise the leaked state value? I would assume 
the legit client binds it to a certain user agent, e.g. via the session 
context, which is not available to the attacker.

best regards,
Torsten.

 Originalnachricht 
Betreff: Re: [OAUTH-WG] State Leakage Attack
Von: Daniel Fett 
An: Antonio Sanso 
Cc: Guido Schmitz ,oauth@ietf.org,Ralf 
Kuesters 

>Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
>> hi Daniel
>> 
>> On Apr 22, 2016, at 4:35 PM, Daniel Fett > > wrote:
>> 
>>> Hi Antonio,
>>>
>>> Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
> Hi all,
>
> During our formal analysis of OAuth we found an attack that allows
> CSRF. It is similar to the "code" leak described by Homakov in [1] and
> therefore not really surprising. In this attack, the intention for an
> attacker is to steal the "state" value instead of the "code" value.
>
> Setting:
>
> In the auth code grant, after authentication to the AS, the user is
> redirected to some page on the Client. If this page leaks the
> referrer, i.e., there is a link to the attacker's website or some
> resource is loaded from the attacker, then the attacker can see not
> only code but also state in the Referer header of the request.
>
> The fact that code can leak was described in [1]. Since code is
> single-use, it might be already redeemed in most cases when it is sent
> to the attacker.

 probably is not redeemed instead, just because the redirect_uri is
 not the correct one.
 The mitigation that good implemented AS use (also Github) is to
 follow section 4.1.3 the OAuth core specification [RFC6749], in
 particular:

 "ensure that the "redirect_uri" parameter is present if the
 "redirect_uri" parameter was included in the initial authorization
 request as described in Section 4.1.1, and if included ensure that
 their values are identical."
>>>
>>> The attack is not based on a manipulation of the redirect_uri. Instead,
>>> a correct redirect_uri is used, but the page loaded from the
>>> redirect_uri contains links or external resources (intentionally or not).
>> 
>> right. so is not really [1] :) since there there is manipulation using
>> /../../ 
>
>Of course.
>
>> Now the real question why a legit redirect_uri should contain links to
>> malicious external resources?
>
>Well, why not? :)
>
>Anyway, developers should be made aware that having external
>resources/links on these pages is a bad idea.
>
>- Daniel
>
>-- 
>Informationssicherheit und Kryptografie
>Universität Trier - Tel. 0651 201 2847 - H436
>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

[Fregly, Andrew]

Hi George,

You have the flow right for how I have been approaching the problem. Note that 
the client doesn’t have to be a mobile app, but that represents well what we 
are trying to solve. Per your recommendation, what I am missing in my knowledge 
is a standard for how the AS could be directed to use an external IdP for 
authentication. Not knowing this, I have been assuming the flow you described 
as my “original thinking" would be required. I will do some more research on 
the topic and check back in.

Thanks,
Andy


From: George Fletcher mailto:gffle...@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 1:36 PM
To: "Fregly, Andrew" mailto:afre...@verisign.com>>, John 
Bradley mailto:ve7...@ve7jtb.com>>, 
"oauth@ietf.org" mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token 
Exchange: An STS for the REST of Us” to include Authentication Tokens

Hi Andy,

Glad I guessed correctly:) If there are network or other limitations in how the 
client gets and uses tokens, that would be helpful in a diagram sense. As John 
points out in his response, not having an audience has possible security 
implications.

If I'm following your original thinking... it goes something like this...

1. Mobile app asks users to authenticate at "their" IdP
2. Mobile app gets back "authentication token" (likely some sort of SAML 
assertion)
3. Mobile app presents "authentication token" to Authorization Service
4. Authorization Service validate "authentication token" and returns an 
access_token
5. Mobile app invokes data provider passing the access_token
6. Data provider validates access_token (either locally or via an introspection 
endpoint on the AS)

In this flow there are really two tokens: the "authentication token" and the 
access_token. There should be an audience for both tokens. The audience of the 
"authentication token" should be the AS, and the audience of the access_token 
should be the data provider the client is going to use.

So, if there are no network firewall type limitations, it seems much simpler to 
just have the AS use the external IdPs as it's authentication mechanisms and 
the rest is just default OpenID Connect. Meaning that the Mobile app starts an 
OpenID Connect flow with the AS, the AS get the user authenticated via the 
user's IdP, the AS provides access and id tokens bask to the Mobile app 
(following the code or other flow).

Am I missing something?

Thanks,
George

On 4/20/16 10:31 AM, Fregly, Andrew wrote:
Hi George,

You fully captured one of the options we have been contemplating. I didn’t 
propose this flow because I was looking for a way to solve our our use case 
based on the existing RFCs and OpenID Connect specifications with minimal new 
specification required. That led me to the path described in the email response 
I sent out a little while ago to Nat Sakimura’s response. Please take a look at 
that email and see what you think.

Given how well stated your summary of our needs was, do you still want me to 
provide a diagram?

Thanks,
Andy

From: George Fletcher mailto:gffle...@aol.com>>
Organization: AOL LLC
Date: Wednesday, April 20, 2016 at 8:49 AM
To: Andrew Fregly 
<afre...@verisign.com>,
 John Bradley mailto:ve7...@ve7jtb.com>>, 
"oauth@ietf.org" 
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token 
Exchange: An STS for the REST of Us” to include Authentication Tokens

I should probably just wait for the diagram... but not wanting to wait... :)

If I understand correctly, the user is going to use a client and the client 
will authenticate the user via some IdP using an existing method (SAML, LDAP 
(?), OpenID Connect, etc). The desire is to take that response and in some way 
present it to an "Authorization Server" which will validate the "authentication 
response" and return an access token for use at the data provider(s).

What if the Authorization Server also took on the role of the OpenID Connect 
provider. This could work by having the client start an OpenID Connect flow 
with Authorization Server (hints could be provided as to which IdP the user 
wants to authenticate at). The AS would look at the "idp hint" and either start 
and SP SAML flow, or present UI for collecting LDAP credentials (I don't 
recommend this) or chain to any other proprietary IdP flow. Once the user 
successfully authenticates with the correct IdP, the AS will finish the OpenID 
Connect flow allowing the client to obtain an access token, refresh token and 
id_token. The AS could add to the id_token a claim specifying which IdP the 
user used during the authentication processed.

The IdP the user used for authentication could also be encoded in the 
access_token (or returned as part of an introspection call).

This way whether the data providers are validat

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

On Apr 22, 2016, at 4:42 PM, Daniel Fett 
mailto:f...@uni-trier.de>> wrote:

Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
hi Daniel

On Apr 22, 2016, at 4:35 PM, Daniel Fett 
mailto:f...@uni-trier.de>
> wrote:

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

probably is not redeemed instead, just because the redirect_uri is
not the correct one.
The mitigation that good implemented AS use (also Github) is to
follow section 4.1.3 the OAuth core specification [RFC6749], in
particular:

"ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization
request as described in Section 4.1.1, and if included ensure that
their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

right. so is not really [1] :) since there there is manipulation using
/../../

Of course.

Now the real question why a legit redirect_uri should contain links to
malicious external resources?

Well, why not? :)

Anyway, developers should be made aware that having external
resources/links on these pages is a bad idea.

agree about the awareness.
It is more likely that such a page contains resource/links e.g. in the form of 
http://ajax.googleapis.com/ajax/libs/angularjs/1.2.23/angular.js";>
 .
In this case IMHO this is more a privacy issue rather than a real security 
threat.

regards

antonio


- Daniel

--
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Daniel Fett]

Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
> hi Daniel
> 
> On Apr 22, 2016, at 4:35 PM, Daniel Fett  > wrote:
> 
>> Hi Antonio,
>>
>> Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
 Hi all,

 During our formal analysis of OAuth we found an attack that allows
 CSRF. It is similar to the "code" leak described by Homakov in [1] and
 therefore not really surprising. In this attack, the intention for an
 attacker is to steal the "state" value instead of the "code" value.

 Setting:

 In the auth code grant, after authentication to the AS, the user is
 redirected to some page on the Client. If this page leaks the
 referrer, i.e., there is a link to the attacker's website or some
 resource is loaded from the attacker, then the attacker can see not
 only code but also state in the Referer header of the request.

 The fact that code can leak was described in [1]. Since code is
 single-use, it might be already redeemed in most cases when it is sent
 to the attacker.
>>>
>>> probably is not redeemed instead, just because the redirect_uri is
>>> not the correct one.
>>> The mitigation that good implemented AS use (also Github) is to
>>> follow section 4.1.3 the OAuth core specification [RFC6749], in
>>> particular:
>>>
>>> "ensure that the "redirect_uri" parameter is present if the
>>> "redirect_uri" parameter was included in the initial authorization
>>> request as described in Section 4.1.1, and if included ensure that
>>> their values are identical."
>>
>> The attack is not based on a manipulation of the redirect_uri. Instead,
>> a correct redirect_uri is used, but the page loaded from the
>> redirect_uri contains links or external resources (intentionally or not).
> 
> right. so is not really [1] :) since there there is manipulation using
> /../../ 

Of course.

> Now the real question why a legit redirect_uri should contain links to
> malicious external resources?

Well, why not? :)

Anyway, developers should be made aware that having external
resources/links on these pages is a bad idea.

- Daniel

-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Daniel Fett]

Am 22.04.2016 um 16:35 schrieb Daniel Fett:
> The attack is not based on a manipulation of the redirect_uri. Instead,
> a correct redirect_uri is used, but the page loaded from the
> redirect_uri contains links or external resources (intentionally or not).

(This of course describes our attack, not the one by Homakov.)


-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

hi Daniel

On Apr 22, 2016, at 4:35 PM, Daniel Fett 
mailto:f...@uni-trier.de>> wrote:

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

probably is not redeemed instead, just because the redirect_uri is not the 
correct one.
The mitigation that good implemented AS use (also Github) is to follow section 
4.1.3 the OAuth core specification [RFC6749], in particular:

"ensure that the "redirect_uri" parameter is present if the "redirect_uri" 
parameter was included in the initial authorization request as described in 
Section 4.1.1, and if included ensure that their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

right. so is not really [1] :) since there there is manipulation using /../../
Now the real question why a legit redirect_uri should contain links to 
malicious external resources?

regards

antonio

[1] http://homakov.blogspot.ch/2014/02/how-i-hacked-github-again.html


- Daniel



--
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Daniel Fett]

Hi Antonio,

Am 22.04.2016 um 16:30 schrieb Antonio Sanso:
>> Hi all,
>>
>> During our formal analysis of OAuth we found an attack that allows
>> CSRF. It is similar to the "code" leak described by Homakov in [1] and
>> therefore not really surprising. In this attack, the intention for an
>> attacker is to steal the "state" value instead of the "code" value.
>>
>> Setting:
>>
>> In the auth code grant, after authentication to the AS, the user is
>> redirected to some page on the Client. If this page leaks the
>> referrer, i.e., there is a link to the attacker's website or some
>> resource is loaded from the attacker, then the attacker can see not
>> only code but also state in the Referer header of the request.
>>
>> The fact that code can leak was described in [1]. Since code is
>> single-use, it might be already redeemed in most cases when it is sent
>> to the attacker.
> 
> probably is not redeemed instead, just because the redirect_uri is not the 
> correct one.
> The mitigation that good implemented AS use (also Github) is to follow 
> section 4.1.3 the OAuth core specification [RFC6749], in particular:
> 
> "ensure that the "redirect_uri" parameter is present if the "redirect_uri" 
> parameter was included in the initial authorization request as described in 
> Section 4.1.1, and if included ensure that their values are identical."

The attack is not based on a manipulation of the redirect_uri. Instead,
a correct redirect_uri is used, but the page loaded from the
redirect_uri contains links or external resources (intentionally or not).

- Daniel



-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] State Leakage Attack

[Antonio Sanso]

hi Daniel

On Apr 22, 2016, at 4:20 PM, Daniel Fett  wrote:

> Hi all,
> 
> During our formal analysis of OAuth we found an attack that allows
> CSRF. It is similar to the "code" leak described by Homakov in [1] and
> therefore not really surprising. In this attack, the intention for an
> attacker is to steal the "state" value instead of the "code" value.
> 
> Setting:
> 
> In the auth code grant, after authentication to the AS, the user is
> redirected to some page on the Client. If this page leaks the
> referrer, i.e., there is a link to the attacker's website or some
> resource is loaded from the attacker, then the attacker can see not
> only code but also state in the Referer header of the request.
> 
> The fact that code can leak was described in [1]. Since code is
> single-use, it might be already redeemed in most cases when it is sent
> to the attacker.

probably is not redeemed instead, just because the redirect_uri is not the 
correct one.
The mitigation that good implemented AS use (also Github) is to follow section 
4.1.3 the OAuth core specification [RFC6749], in particular:

"ensure that the "redirect_uri" parameter is present if the "redirect_uri" 
parameter was included in the initial authorization request as described in 
Section 4.1.1, and if included ensure that their values are identical."

regards

antonio


> State, however, is not limited to a single use (by 6749 or others) and
> therefore can be used by the attacker to mount a CSRF attack and
> inject his own code into a (new) auth code grant.
> 
> We suggest
> a) making state single use, and
> b) highlighting to developers the importance of non-leaky redirection
> endpoints, and to this end
> c) recommending the use of "referrer policies" [2] to mitigate such attacks.
> 
> Could somebody confirm whether this attack is new?
> 
> Cheers,
> Daniel, Guido, and Ralf
> 
> [1] http://homakov.blogspot.de/2014/02/how-i-hacked-github-again.html
> [2] https://w3c.github.io/webappsec-referrer-policy/
> -- 
> Informationssicherheit und Kryptografie
> Universität Trier - Tel. 0651 201 2847 - H436
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Multi-AS State Re-Use

[Daniel Fett]

Hi all,

Besides the state leakage attack we found that another important fact
regarding state is underspecified: Each state value should only be
used for one run of the protocol, in particular, each AS should see a
different state in multi-AS settings. Clients might be tempted to
generate state once and then re-use each time a user wants to
authorize.

If state is re-used, given a setup where one Client allows users to
authorize using two AS, a potentially malicious AS learns the state
value that is valid for authorization at an honest AS. I.e., each AS
can mount a CSRF attack on the user using the other AS.

Just as the attack in the other mail, this is not a big deal in
practice, but should be discussed somewhere.

Cheers,
Daniel, Guido, and Ralf
-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] State Leakage Attack

[Daniel Fett]

Hi all,

During our formal analysis of OAuth we found an attack that allows
CSRF. It is similar to the "code" leak described by Homakov in [1] and
therefore not really surprising. In this attack, the intention for an
attacker is to steal the "state" value instead of the "code" value.

Setting:

In the auth code grant, after authentication to the AS, the user is
redirected to some page on the Client. If this page leaks the
referrer, i.e., there is a link to the attacker's website or some
resource is loaded from the attacker, then the attacker can see not
only code but also state in the Referer header of the request.

The fact that code can leak was described in [1]. Since code is
single-use, it might be already redeemed in most cases when it is sent
to the attacker.

State, however, is not limited to a single use (by 6749 or others) and
therefore can be used by the attacker to mount a CSRF attack and
inject his own code into a (new) auth code grant.

We suggest
a) making state single use, and
b) highlighting to developers the importance of non-leaky redirection
endpoints, and to this end
c) recommending the use of "referrer policies" [2] to mitigate such attacks.

Could somebody confirm whether this attack is new?

Cheers,
Daniel, Guido, and Ralf

[1] http://homakov.blogspot.de/2014/02/how-i-hacked-github-again.html
[2] https://w3c.github.io/webappsec-referrer-policy/
-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth