Re: [OAUTH-WG] State Leakage Attack

["[e-mail]" <[e-mail]>]

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 <[e-mail]>
An: Antonio Sanso <[e-mail]>
Cc: Guido Schmitz <[e-mail]>,[e-mail],Ralf Kuesters <[e-mail]>

>Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
>> hi Daniel
>> 
>> On Apr 22, 2016, at 4:35 PM, Daniel Fett <[e-mail]
>> <mailto:[e-mail]>> 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. [phone] - H436
>
>_______________________________________________
>OAuth mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/oauth
>