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.) > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
