Re: [OAUTH-WG] State Leakage Attack

I overlooked that one-time use was suggested in the original report; sorry.
I agree with the mitigation, and that client developers should be made
aware.

Andre DeMarre
On Apr 23, 2016 6:51 AM, "André DeMarre" <andredemarre@gmail.com> wrote:

A client that implements state values as one-time use would not be affected
by this leakage. The state would be invalidated before it got leaked.

Andre DeMarre
On Apr 23, 2016 4:19 AM, "Thomas Broyer" <t.broyer@gmail.com> wrote:

>
>
> On Sat, Apr 23, 2016 at 12:49 PM Guido Schmitz <g.schmitz@gtrs.de> wrote:
>
>> Hi Torsten,
>>
>> as the state value is supposed to protect the user agent's session
>> against CSRF attacks, an attacker can use the leaked state value to
>> perform a CSRF attack against this user agent.
>>
>> The attacker can, for example, redirect the user agent to the client's
>> redirection endpoint (again) and by this, overwrite the previously
>> performed authorization. When the client then contacts some RS (in the
>> context of the user under attack), it may use an access token linked to
>> the attacker's account (instead of an access token linked to the user's
>> account) at the RS. The effects of such an attack are similar to a
>> session swapping attack. The attacker does not need to access the
>> session context directly (which may bound to the user agent), as he
>> instructs the correct user agent to perform these actions.
>>
>
> +1
>
> This is briefly and indirectly touched in
> https://tools.ietf.org/html/rfc6819#section-4.4.2.5
>
>       This will ensure that the client is not tricked into completing
>       any redirect callback unless it is linked to an authorization
>       request initiated by the client.
>
> But this is clearly not explicit (and could very well be just by luck);
> note: the key here being "an authorization request initiated by the client".
>
> So, I agree about the validity of the attack and the suggested mitigation
> (disclaimer: I'm in no way a security expert, only just a web dev), and I
> haven't seen this attack described anywhere.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>