Re: [OAUTH-WG] State Leakage Attack

aturday, April 23, 2016 10:46 PM An: Torsten Lodderstedt <mailto:tors...@lodderstedt.net>>,Guido Schmitz <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 mailto

Re: [OAUTH-WG] State Leakage Attack

Yes that policy will be in new browsers but that will not be all browsers for some time (probably not until XP dies) We are going to have the old browser issue with Token binding as well. At some point AS may need to restrict what older browsers can do as they will have different security prof

Re: [OAUTH-WG] State Leakage Attack

Inline > On Apr 25, 2016, at 6:01 AM, Daniel Fett wrote: > > Am 24.04.2016 um 22:31 schrieb John Bradley: >> I described a similar attack at the meeting in Darmstadt. Using stolen >> state to inject code from a different session. >> >> We were calling that the cut and paste attack. The propo

Re: [OAUTH-WG] State Leakage Attack

Am 25.04.2016 um 15:11 schrieb Antonio Sanso: >>> Checking referrer is a weak protection at best, as that is easily faked in >>> many circumstances. >> >> Note that we do not propose checking the referrer as a mitigation; we >> propose using the referrer policy (at the client) to suppress the >> r

Re: [OAUTH-WG] State Leakage Attack

hi On Apr 25, 2016, at 3:01 PM, Daniel Fett wrote: > Am 24.04.2016 um 22:31 schrieb John Bradley: >> I described a similar attack at the meeting in Darmstadt. Using stolen >> state to inject code from a different session. >> >> We were calling that the cut and paste attack. The proposed mit

Re: [OAUTH-WG] State Leakage Attack

Am 24.04.2016 um 22:31 schrieb John Bradley: > I described a similar attack at the meeting in Darmstadt. Using stolen state > to inject code from a different session. > > We were calling that the cut and paste attack. The proposed mitigation is > ing the draft that Mike and I did. > > This w

Re: [OAUTH-WG] State Leakage Attack

Ursprüngliche Nachricht > Von: Thomas Broyer > Gesendet: Saturday, April 23, 2016 10:46 PM > An: Torsten Lodderstedt ,Guido Schmitz > ,oauth@ietf.org > Betreff: Re: [OAUTH-WG] State Leakage Attack > > > > On Sat, Apr 23, 2016 at 3:56 PM Torsten Lodderstedt &l

Re: [OAUTH-WG] State Leakage Attack

I described a similar attack at the meeting in Darmstadt. Using stolen state to inject code from a different session. We were calling that the cut and paste attack. The proposed mitigation is ing the draft that Mike and I did. This was based on the attacker making a new request in a differen

Re: [OAUTH-WG] State Leakage Attack

:-) Ursprüngliche Nachricht Von: Thomas Broyer Gesendet: Saturday, April 23, 2016 10:46 PM An: Torsten Lodderstedt ,Guido Schmitz ,oauth@ietf.org Betreff: Re: [OAUTH-WG] State Leakage Attack >On Sat, Apr 23, 2016 at 3:56 PM Torsten Lodderstedt >wrote: > >> I d

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] 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] 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

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: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

Re: [OAUTH-WG] State Leakage Attack

the legit client binds it to a certain user agent, e.g. via the session context, which is not available to the attacker. best regards, Torsten. Originalnachricht -------- Betreff: Re: [OAUTH-WG] State Leakage Attack Von: Daniel Fett An: Antonio Sanso Cc: Guido Schmitz ,oauth@ie

Re: [OAUTH-WG] State Leakage Attack

---- Originalnachricht > Betreff: Re: [OAUTH-WG] State Leakage Attack > Von: Daniel Fett > An: Antonio Sanso > Cc: Guido Schmitz ,oauth@ietf.org,Ralf > Kuesters > > Am 22.04.2016 um 16:39 schrieb Antonio Sanso: >> hi Daniel >> >> On Apr 22, 2

Re: [OAUTH-WG] State Leakage Attack

] State Leakage Attack Von: Daniel Fett An: Antonio Sanso Cc: Guido Schmitz ,oauth@ietf.org,Ralf Kuesters >Am 22.04.2016 um 16:39 schrieb Antonio Sanso: >> hi Daniel >> >> On Apr 22, 2016, at 4:35 PM, Daniel Fett > <mailto:f...@uni-trier.de>> wrote: >> &

Re: [OAUTH-WG] State Leakage Attack

On Apr 22, 2016, at 4:42 PM, Daniel Fett mailto:f...@uni-trier.de>> wrote: Am 22.04.2016 um 16:39 schrieb Antonio Sanso: hi Daniel On Apr 22, 2016, at 4:35 PM, Daniel Fett mailto:f...@uni-trier.de> > wrote: Hi Antonio, Am 22.04.2016 um 16:30 schrieb Antonio Sanso: H

Re: [OAUTH-WG] State Leakage Attack

Am 22.04.2016 um 16:39 schrieb Antonio Sanso: > hi Daniel > > On Apr 22, 2016, at 4:35 PM, Daniel Fett > wrote: > >> Hi Antonio, >> >> Am 22.04.2016 um 16:30 schrieb Antonio Sanso: Hi all, During our formal analysis of OAuth we found an attack that allows

Re: [OAUTH-WG] State Leakage Attack

Am 22.04.2016 um 16:35 schrieb Daniel Fett: > The attack is not based on a manipulation of the redirect_uri. Instead, > a correct redirect_uri is used, but the page loaded from the > redirect_uri contains links or external resources (intentionally or not). (This of course describes our attack, not

Re: [OAUTH-WG] State Leakage Attack

hi Daniel On Apr 22, 2016, at 4:35 PM, Daniel Fett mailto:f...@uni-trier.de>> wrote: Hi Antonio, Am 22.04.2016 um 16:30 schrieb Antonio Sanso: Hi all, During our formal analysis of OAuth we found an attack that allows CSRF. It is similar to the "code" leak described by Homakov in [1] and there

Re: [OAUTH-WG] State Leakage Attack

Hi Antonio, Am 22.04.2016 um 16:30 schrieb Antonio Sanso: >> Hi all, >> >> During our formal analysis of OAuth we found an attack that allows >> CSRF. It is similar to the "code" leak described by Homakov in [1] and >> therefore not really surprising. In this attack, the intention for an >> attack

Re: [OAUTH-WG] State Leakage Attack

hi Daniel On Apr 22, 2016, at 4:20 PM, Daniel Fett wrote: > Hi all, > > During our formal analysis of OAuth we found an attack that allows > CSRF. It is similar to the "code" leak described by Homakov in [1] and > therefore not really surprising. In this attack, the intention for an > attacker

[OAUTH-WG] State Leakage Attack

Hi all, During our formal analysis of OAuth we found an attack that allows CSRF. It is similar to the "code" leak described by Homakov in [1] and therefore not really surprising. In this attack, the intention for an attacker is to steal the "state" value instead of the "code" value. Setting: In