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 <f...@uni-trier.de>
An: Antonio Sanso <asa...@adobe.com>
Cc: Guido Schmitz <gschm...@informatik.uni-trier.de>,oauth@ietf.org,Ralf
Kuesters <kuest...@uni-trier.de>
>Am 22.04.2016 um 16:39 schrieb Antonio Sanso:
>> hi Daniel
>>
>> On Apr 22, 2016, at 4:35 PM, Daniel Fett <f...@uni-trier.de
>> <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.
>
>- 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
