On Sat, Apr 23, 2016 at 12:49 PM Guido Schmitz <g.schm...@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
