Understood. Thanks. So this is basically a way to circumvent XSRF protection. OWASP has an excellent description of the attack and mitigations https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet - It recommends per-request CSRF tokens for state changes via GET requests. Same conclusion:-)
-------- Ursprüngliche Nachricht -------- Von: Thomas Broyer <t.bro...@gmail.com> Gesendet: Saturday, April 23, 2016 10:46 PM An: Torsten Lodderstedt <tors...@lodderstedt.net>,Guido Schmitz <g.schm...@gtrs.de>,oauth@ietf.org Betreff: Re: [OAUTH-WG] State Leakage Attack >On Sat, Apr 23, 2016 at 3:56 PM Torsten Lodderstedt <tors...@lodderstedt.net> >wrote: > >> I don't think this is possible if the client checks whether the state >> actually belongs to its local session before it processes it. >> > >It does so in step 3 below, and it accepts it because: a) the value is the >same, as it leaked and the attacker reinjected the leaked value, and b) the >client didn't invalidate the value after first use in step 1. > > >> Am 23.04.2016 um 15:53 schrieb Thomas Broyer: >> >> >> >> On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt < >> tors...@lodderstedt.net> wrote: >> >>> Hi Guido, >>> >>> do I get it right. The attacker is supposed to use the state value in >>> order to overwrite the user agent's session state? >>> >> >> Most apps only ever remember a single access token, so by re-using the >> state the attacker could override the access token by injecting an >> authorization code at the redirection_uri, tricking it to accepting the >> request by injecting a known (leaked) "state" value. >> >> Flow is: >> 1. victim app makes a normal OAuth code flow but: >> 1a. doesn't invalidate the "state" upon return, making it reusable >> 1b. leaks the "state" to the attacker >> It stores the access token into the session. >> 2. attacker starts a normal OAuth code flow, using the victim app's >> redirect_uri, and "intercepts" the "code", which it injects to the victim >> app's redirection endpoint, along with the leaked state, through the victim >> user's browser. Note that the "code" is bound to the attacker's account. >> 3. the victim app, validates the "state" and accepts the request, so it >> exchanges the code for an access token, and stores it in its session, >> replacing the previous one. This means that the victim's session now uses >> an access token that's actually bound to the attacker's account. >> >> Easy mitigation is to have one-time state values (i.e. state is somehow >> bound to the authorization request, not just the "user session") >> >> Furthermore, IFF the original OAuth code flow was in error (for whichever >> reason) and/or was tricked to a bad redirect_uri (like in Homakov's code >> leak attack) such that no "code" is redeemed; then the attacker could >> possibly use this to link the victim user's account at the victim app to >> the attacker's account at the AS (relying on inexistant association of >> accounts at the victim app and AS), allowing the attacker to authenticate >> to the victim user's account on the victim app using the attacker's >> credentials (well-known social login / linked accounts attack). >> >> >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
