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