The only way to prevent early binding is, well, not to do it. There is no cure for bad developers.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Jesse Myers > Sent: Thursday, April 30, 2009 9:02 AM > To: [email protected] > Subject: [oauth] Re: An OAuth attack on Consumer implementations > > > Eran, Good to hear. > > Darren, if you're concerned about early binding, a few people have > suggested limiting the number of times a request token can be used > within an authorization URL and limiting the amount of time that can > elapse before it is used. Together, these restrictions make embedding > an authorization URL in a blog, spam, etc. impractical. However, since > some OAuth scenarios require authorization to be manual, I suspect > these ideas will just be guidelines, not a part of the spec. > > Jesse > > > On Thu, Apr 30, 2009 at 8:54 AM, Eran Hammer-Lahav > <[email protected]> wrote: > > We call this 'early binding' and it will be directly addressed in a > security > > consideration section. > > > > > > > > EHL > > > > > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of > > Darren Bounds > > Sent: Thursday, April 30, 2009 7:36 AM > > To: [email protected] > > Subject: [oauth] An OAuth attack on Consumer implementations > > > > > > > > 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&fo > rmat=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] > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
