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 <dar...@cliqset.com> 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 <e...@hueniverse.com> > Date: Thu, Apr 30, 2009 at 3:25 AM > Subject: [oauth] OAuth Core 1.0 Rev A, Draft 1 > To: "oauth@googlegroups.com" <oauth@googlegroups.com> > > > > 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 > dar...@cliqset.com > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
