According to the language in Rev A, the purpose of the verification code is to ensure the user performing the authorization at the SP is the same user who returns back to the Consumer.
"In order to ensure that the User granting access is the same User returning back to the Consumer to complete the process, the Service Provider MUST generate a verification code: a non-guessable value passed to the Consumer via the User and REQUIRED to complete the process." With Rev A, the verification code is introduced *after* the OAuth process has initiated and the user is already at the SP. In the case of the attack I've described, the user authorizing the action *is* the same user who's returning to the Consumer. The problem arises when the Consumer assigns the Access Token/Secret to the designated user after the negotiation is completed due to the fact the initiating user is not the user who completed the negotiation. I've read the spec several times now so if I've missed something glaringly obvious that mitigates this, please spell it out. I won't be offended. :) Darren On Thu, Apr 30, 2009 at 11:05 AM, Blaine Cook <[email protected]> wrote: > > That's the same attack as the one addressed in Rev. A; the > verification token means that the consumer will always know which user > with which to associate the access token (i.e., the user that brings > the verification token to the consumer, not the user that initiated > the flow). > > b. > > On Thu, Apr 30, 2009 at 3:35 PM, Darren Bounds <[email protected]> wrote: > > Last week while pondering the vulnerability and the proposed solutions, I > > began thinking of the consumer assumptions being made and another > possible > > avenue of attack that I personally think needs to be called out in an > > appendix. > > > > The attack is a derivative of the session fixation attack but is really > much > > more reliant on an improper implementation on the Consumer end. To that > end; > > the Rev A does not address this issue and likely shouldn't. It is made > > possible by a relatively specific, and what I feel is a quite probable, > > consumer configuration where the OAuth negotiation is permanently bound > to > > the initiating user identity for the duration of its life cycle. > > > > It looks like this: > > > > Consumer App 1: A legitimate application that provides the ability to > > publish Twitter status updates via OAuth. > > > > 1) Attacker authenticates to Consumer App 1. > > 2) Attacker initiates an OAuth exchange with Twitter, capturing the OAuth > > redirect URL. > > 3) Attacker embeds the URL in his blog and coerces the Victim user into > > clicking it (how is out of scope). > > 4) Victim user is brought to Twitter and prompted to authenticate and > > authorize his association with Consumer App 1. > > 5) Victim is then redirected to Consumer App 1 to complete the OAuth > > handshake. > > 6) Because Consumer App 1 does not take into account the possibility that > > the user who initiated the exchange isn't the same as the one who > returned, > > the Consumer App 1 completes the OAuth negotiation and associates the > Access > > Token and Access Token Secret with the Attacker. > > 7) Attacker now has access to Victims protected Twitter resources. > > > > While this attack scenario is dependent on a Consumer specific logic > > structure, without a fairly deep understanding of OAuth and general > security > > principles (which unfortunately many do not have) this could be > considered a > > very plausible implementation. > > > > I feel it is important to mention to Consumer application implementers > that > > they cannot trust that the user who initiated the OAuth negotiation is > the > > same as the one who completed it. Subsequently, the association of an > OAuth > > Access Token and Access Token Secret with a user should only be based on > > material collected from the user who completed the transaction. > > > > Thoughts? > > > > Darren > > > > > > ---------- Forwarded message ---------- > > From: Eran Hammer-Lahav <[email protected]> > > Date: Thu, Apr 30, 2009 at 3:25 AM > > Subject: [oauth] OAuth Core 1.0 Rev A, Draft 1 > > To: "[email protected]" <[email protected]> > > > > > > > > Please review: > > > > > http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html > > > > I did my best to keep the changes to a bare minimum and to avoid any > > editorial changes to make comparison trivial: > > > > > http://code.google.com/p/oauth/source/diff?spec=svn992&old=991&r=992&format=unidiff&path=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml > > > > Some notes: > > > > 1. This is not ready for code! Please wait for a second draft before you > > start making changes to libraries or your implementations. Given the > small > > scope of this change, I think it will be stable in the next draft. > > > > 2. Since this change is small, I would like to give it a short review > period > > before another draft. Please submit all your comments by May 8th. > > > > 3. This draft is missing a few new Security Consideration sections. It > will > > be added in the next draft but might be shared earlier on the list. > > > > 4. This revision does not change the value of the oauth_version parameter > > which remains '1.0'. The reason for that is that the version has nothing > to > > do with the authorization workflow. It is specific to the signature > methods > > and parameter delivery methods. Telling the difference between the two > > revisions is very simple: look for an oauth_callback parameter in the > > Request Token step. > > > > 5. The reason why the oauth_callback parameter is now required with a > 'oob' > > value for manual entry is because the presence of the oauth_callback > > parameter in the first step is the only indication which flow is being > used. > > Since some platforms have problem with empty parameters (they are dropped > or > > not sent on the wire), I decided to try and define a non-URL value (also > > made the URL absolute). > > > > NOTE: Do no suggest ANY editorial changes that are not specific to the > > changed sections. This is NOT an opportunity to improve the > specification. > > If you want to improve the specification in general, please provider > > feedback to the Editor's Cut version. > > > > Tomorrow, I will post an updated Editor's Cut version as well as an > update > > to the IETF draft to include these changes. > > > > EHL > > > > > > > > > > > > > > -- > > darren bounds > > [email protected] > > > > > > > > > > > > > > > -- darren bounds [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
