Cool. Are there any other new security consideration sections we need to add, or is this the only one?
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Brian Eaton > Sent: Friday, May 08, 2009 3:39 PM > To: [email protected] > Subject: [oauth] Re: Request for new Security Considerations text > > > I like it. > > On Fri, May 8, 2009 at 3:35 PM, Darren Bounds <[email protected]> > wrote: > > > > I'm good with that. So we're left with: > > > > Cross-Site Request Forgery (CSRF) Attacks > > > > Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP > > requests are transmitted from a user that the website trusts or has > > authenticated. > > > > CSRF attacks on OAuth approvals can allow an attacker to obtain > > authorization to OAuth protected resources without the consent of the > > resource owner. Service Providers should strongly consider best > > practices in CSRF prevention at all OAuth endpoints. > > > > CSRF attacks on OAuth callback URLs hosted by Consumers are also > > possible. Consumers should prevent CSRF attacks on OAuth callback > URLs > > by verifying that the user at the consumer site intended to complete > > the OAuth negotiation with the service provider. > > > > > > Darren > > On Fri, May 8, 2009 at 6:28 PM, Brian Eaton <[email protected]> > wrote: > >> > >> On Fri, May 8, 2009 at 3:16 PM, Darren Bounds <[email protected]> > wrote: > >>> While that's nice to have, I do not believe it's necessary to foil > the > >>> attack. Acting purely on the identity of the user completes the > OAuth > >>> dance is enough and can still be considered a secure consumer > >>> implementation. > >> > >> Not unless there is a user consent page presented before the > consumer > >> completes the linkage. You need some kind of user consent at the > >> consumer side to verify that the user really intended to link the SP > >> account to the consumer account. > >> > >> This is not totally out of the realms of normal CSRF protection, but > >> it is a bit subtle. How about this: > >> > >> "CSRF attacks on OAuth callback URLs hosted by Consumers are also > >> possible. Consumers should prevent CSRF attacks on OAuth callback > >> URLs by verifying that the user at the consumer site intended to > >> complete the OAuth negotiation with the service provider." > >> > >> User intent can be divined in one of two ways: > >> 1) "mixed binding", where you make sure the user who started the > >> process and the user who finished it are the same. > >> 2) "late binding", where the consumer asks the user whether they > want > >> to link their account. > >> > >> There are real-world examples of late binding being very useful as a > >> UI optimization: > >> http://code.google.com/apis/gadgets/docs/oauth.html#skip_popup > >> > >> Cheers, > >> Brian > >> > >> > > >> > > > > > > > > -- > > 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 -~----------~----~----~----~------~----~------~--~---
