Hi Ethan, I agree with the assessment, i.e., that XSRF protections can in theory prevent against interception attacks. In practice, however, a MitM attacker would typically have access to cookies and so in practice would 'own' the user's account at the consumer already. No matter how you look at it, a MitM attacker is too powerful a scenario.
On Fri, Sep 25, 2009 at 10:39 AM, Ethan Jewett <[email protected]> wrote: > > Hi Breno and Simone, > > I disagree. I believe that in order to perform a MITM attack against > properly implemented 1.0a, the MITM would need to intercept the > response *and* be able to prove to the consumer that it is the user > that originally requested access. In other words, it would have to > already own the user account on the consumer, meaning that a MITM > attack would not be necessary at all. > > By "properly implemented", I mean that the consumer application checks > that the user who is redirected back to the consumer is the same user > that initiated the authentication request, usually by requiring the > user to be logged in at the callback URL. > > Looking back at the spec, this is probably not clear in the body of > the spec, but is addressed in the security considerations section. For > example: > http://tools.ietf.org/html/draft-ietf-oauth-web-delegation-01#section-8.6 > > Ethan > > On Fri, Sep 25, 2009 at 10:48 AM, Breno de Medeiros <[email protected]> > wrote: > > > > Hi Simone, > > > > Yes, interception is possible. Note, however, that the URL to return > > the user to is signed in the consumer's initial request, so it is not > > possible to mis-direct the user. So to intercept the response the > > attacker needs to perform a Man-in-the-Middle attack. Typical > > protections against MitM can then be used (e.g., use SSL at the > > provider and consumer endpoints). > > > > > > > > On Fri, Sep 25, 2009 at 7:46 AM, Simone <[email protected]> wrote: > >> > >> Hi. I would ask you a thing about the unguessable parameter > >> oauth_verifier. > >> In the attack at the core 1.0 specification the intruder not have to > >> intercept anything but only constructs a link for the victim. > >> In the new version of the protocol core 1.0A, when the service > >> provider redirects the user to the consumer with the parameter > >> oauth_verifier, if an intruder intercepts this message with the > >> oauth_verifier, since the message is in clear, cannot the intruder use > >> the oauth_verifier and come back him to the consumer for continue a > >> previous session of the protocol, realizing an attack similar to the > >> that found in the core 1.0 specification? Is there the assumption that > >> the message in the redirection (from the user to the consumer) is not > >> intercepted? > >> Sure the attack is more difficult than the first one because now are > >> need some interceptions, but is possible, or not? > >> > > >> > > > > > > > > -- > > --Breno > > > > +1 (650) 214-1007 desk > > +1 (408) 212-0135 (Grand Central) > > MTV-41-3 : 383-A > > PST (GMT-8) / PDT(GMT-7) > > > > > > > > > > > -- Breno de Medeiros --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
