I can't say that I agree. The fact of the matter is that a lot of developers are going to encounter OAuth for the first time when they first need to integrate with an SP. Most developers will immediately download an OAuth library from somewhere and start to work with it. They probably won't read the OAuth spec and internalize it. If they do read the spec, they may just gloss over whatever disclaimer warns them off of early binding or not have any idea what early binding is.
Maybe this makes these developers bad, but it also makes them typical. I'm strongly in favor of anything that makes it easier for a typical developer to use my SP. One avenue for progress is on the OAuth library side. Most of the libraries I've looked at (not enough yet) provide procedural access to tokens and to make calls to OAuth entry points, but leave it up to the developer to sequence these calls and manage the token data within an application. As we've built out SDKs for our SP, we've found ourself increasingly building this logic on top of OAuth to make it easy to integrate within common web frameworks. Typically, this ends up with a bit of example code that shows how to incorporate content from our SP into a page in one of these frameworks with almost no work. Which is to say, bad developers are cured when good developers do the hard stuff for them. Jesse On Thu, Apr 30, 2009 at 9:28 AM, Eran Hammer-Lahav <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
