Hi John,
Am 24.04.2016 um 22:58 schrieb John Bradley:
I did talk about using “jti" for state replay protection in
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.
So the JTI makes the state value a per-request anti-XSRF token, right?
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.
To prevent mix up (of some kind) :-)
This sort of attack is why the “code id_token” response type in
connect included c_hash and nonce in the Connect id_token.
The nonce is the anti XSRF token in this example, right? So it needs to
be single use as well.
best regards,
Torsten.
John B.
On Apr 24, 2016, at 2:54 AM, tors...@lodderstedt.net
<mailto: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 <mailto:t.bro...@gmail.com>>
Gesendet: Saturday, April 23, 2016 10:46 PM
An: Torsten Lodderstedt <tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>,Guido Schmitz <g.schm...@gtrs.de
<mailto:g.schm...@gtrs.de>>,oauth@ietf.org <mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
