I don't think this is possible if the client checks whether the state
actually belongs to its local session before it processes it. Everything
else seems weird.
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
