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
