[Breno said] > The request token can be stored in a cookie or some other parameter > that provides XSRF protection vis-a-vis the callback URL. This allows > the consumer to remain stateless by doing the right thing.
> James, you made the best argument (in my view) of why we should stick with > the existing proposal, namely that the easiest way to preserve > statelessness is to implement a measure that results in XSRF protection > side effects. This is a curious side-effect -- but not a great basis for protocol design. Only consumer apps that take the effort to be stateless get CSRF protection. It requires clients to support cookies. It assumes other CSRF defences cannot be sufficient (eg using Referer or Origin HTTP headers). 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. Separately, we should write advice for all OAuth consumers about implementing CSRF defences. I assume the issue is "Login CSRF" -- where a victim is "logged in" to the consumer as the attacker [in OAuth, a victim is using a consumer that is accessing a service provider on behalf of an attacker]. >> My guess is that it would require very substantial changes to >> a Consumer App’s architecture if it had to switch from a stateless to a >> statefull mode to support a security fix. > There is no need for such radical changes as described above. Are you sure that the alternative ways to implement statelessness (other than encoding state into the callback) are viable in all situations, and will remain so in the future? Even if that was true, do we have to force consumers to switch how they implement statelessness? -- CSRF = XSRF = cross-site request forgery --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
