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" <andredema...@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.bro...@gmail.com> wrote: > > > 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 > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
