Re: [OAUTH-WG] State Leakage Attack

Hi Torsten, as the state value is supposed to protect the user agent's session against CSRF attacks, an attacker can use the leaked state value to perform a CSRF attack against this user agent. The attacker can, for example, redirect the user agent to the client's redirection endpoint (again) and

Re: [OAUTH-WG] State Leakage Attack

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? best regards, Torsten. Am 23.04.2016 um 12:47 schrieb Guido Schmitz: Hi Torsten, as the state value is supposed to protect the user agent's session against CSRF

Re: [OAUTH-WG] State Leakage Attack

On Sat, Apr 23, 2016 at 12:49 PM Guido Schmitz wrote: > Hi Torsten, > > as the state value is supposed to protect the user agent's session > against CSRF attacks, an attacker can use the leaked state value to > perform a CSRF attack against this user agent. > > The attacker can, for example, redi

[OAUTH-WG] Mix-Up and CnP/ Code injection

Hi all, discussion about Mix-Up and CnP seems to have stopped after the session in BA - at least in the OAuth WG. There is a discussion about mitigations in OpenId Connect going on at the OpenId Connect mailing list. I'm very much interested to find a solution within the OAuth realm as I'm n

Re: [OAUTH-WG] State Leakage Attack

A client that implements state values as one-time use would not be affected by this leakage. The state would be invalidated before it got leaked. Andre DeMarre On Apr 23, 2016 4:19 AM, "Thomas Broyer" wrote: > > > On Sat, Apr 23, 2016 at 12:49 PM Guido Schmitz wrote: > >> Hi Torsten, >> >> as t

Re: [OAUTH-WG] State Leakage Attack

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 th

Re: [OAUTH-WG] State Leakage Attack

I overlooked that one-time use was suggested in the original report; sorry. I agree with the mitigation, and that client developers should be made aware. Andre DeMarre On Apr 23, 2016 6:51 AM, "André DeMarre" wrote: A client that implements state values as one-time use would not be affected by t

Re: [OAUTH-WG] State Leakage Attack

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 mailto:tors...@lodderstedt.net>

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

OpenID Connect defines a third-party login endpoint for RP's, which is what the AS is acting as in this case: http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin -- Justin On 4/22/2016 10:50 AM, Fregly, Andrew wrote: Hi George, You have the flow right for how I hav

Re: [OAUTH-WG] State Leakage Attack

On Sat, Apr 23, 2016 at 3:56 PM Torsten Lodderstedt 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 t

Re: [OAUTH-WG] [Ace] PoP, Introspection and ACE

Thanks John for your reply, have you had time to discuss a way forward with Hannes. I agree we should absolutely register cnf in introspection to go inline with RFC 7800. Since RFC 7800 is done it might be preferable to do the registration in the ACE specification that is the specification that n