I did talk about using “jti" for state replay protection in https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-05 <https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-05>
Not that any developer looks at that ID, but I should probably expand the advice for replay protection for state. We need to remember that a client might have two or more authorization requests in flight at the same time if the user has multiple tabs open. This is a real issue for clients that developers have shared. Supporting that requires more than just keeping a single value that is overwritten. This sort of attack is why the “code id_token” response type in connect included c_hash and nonce in the Connect id_token. John B. > On Apr 24, 2016, at 2:54 AM, tors...@lodderstedt.net wrote: > > 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 > <mailto: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 <mailto: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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
