I do not think there is anything fundamentally wrong with James proposal. However, I have not given it near the same level of scrutiny that I did to the existing proposal. Plenty of eyes were intensely focused on it during the week immediately after the advisory came out. The net result is that the existing proposal was widely discussed and has received 1000's of hours of total attention from developers and security experts by now, from an implementation issues perspective sure, but also critically from a security perspective.
On Wed, May 6, 2009 at 10:56 PM, Eran Hammer-Lahav <[email protected]> wrote: > James, thanks for adding the proposal and offering deeper insight into its > details. I would like to ask you to add it to the wiki page so we have it > documented. > > I would like to ask people if they have strong views for or against this > proposal. So far a few people raised concerns which James tried to addressed, > but I have not heard from anyone who would like to advocate this as the > proposal patch. I think any proposal deserves to be considered, but we need > more people to advocate it for it to remain on the table. > > EHL > > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Manger, James H >> Sent: Wednesday, May 06, 2009 7:31 PM >> To: [email protected] >> Subject: [oauth] Re: Confirm callback when getting access token >> >> Brian, >> >> There are two attacks: attacker gets victim's access; and login CSRF. >> >> They are distinct attacks, causing different damage, and with different >> defences -- but they are both sort of related to session fixation. >> Consequently, I find the term "session fixation" a bit ambiguous in >> these discussions. >> >> The first attack is the OAuth-specific issue that attention is focused >> on. >> >> Callback-with-request-token and callback-with-access-token both address >> the first attack. Neither addresses login CSRF. >> >> A Referer check at the callback URI is one way to combat login CSRF >> against the callback URI. I wasn't suggesting that this defeats the >> first attack as well. >> >> I have earlier suggested a Referer check *at the authorization URI* >> could combat the first attack. I still think that could be quite an >> effective temporary fix, though Allen Tom suggested issues with social >> networking sites that I haven't fully groked. >> >> >> I don't think encoding all state in the callback URI implies a >> vulnerability to session fixation. There is usually no session yet. >> Encoding all state in the callback URI might make it more important to >> explicitly address login CSRF, but they are still separate issues. >> >> Options for client-side state with 1.0 include (at least): >> * callback URI >> * cookies >> * javascript variables >> I don't want to remove any option if we don't have to. JavaScript >> variables presumably fail on clients that disable JavaScript. Cookies >> might be blocked by some clients, don't work across domains, and have >> their own issues. >> >> >> Breno suggested that by removing the callback URI as an option for >> storing state (by adopting callback-with-request-token), developers are >> more likely to choose a state management approach that accidentally >> prevents login CSRF. >> >> I really like the idea of making the easiest option for developers the >> secure choice. However, I feel that while callback-with-request-token >> might make the easiest *remaining* option a secure choice, it only does >> so by eliminating other options that can be easier and still be secure. >> [What is easiest varies with circumstance, of course] >> >> >> James Manger >> [email protected] >> Identity and security team — Chief Technology Office — Telstra >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Brian Eaton >> Sent: Thursday, 7 May 2009 3:44 AM >> To: [email protected] >> Subject: [oauth] Re: Confirm callback when getting access token >> >> >> On Tue, May 5, 2009 at 9:34 PM, Manger, James H >> <[email protected]> wrote: >> > I would prefer to fix OAuth security issue 2009-1 without >> unnecessarily preventing >> > state-management options that previously worked, and without >> requiring cookies where >> > they were not previously necessary. >> >> I'm pretty sure that any client that encodes all state in the callback >> URL is still vulnerable to session fixation. You mentioned using >> referer or origin HTTP headers to prevent XSRF of the callback URL, >> but those don't actually work to prevent the session fixation attack. >> (Referer and Origin will always point to the SP.) >> >> (Nit: the protocol doesn't actually require cookies. Other types of >> client-side state (javascript variables for web browsers, disk or >> memory storage for installed apps) are perfectly viable.) >> >> >> >> > > > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
