I'm being lazy today. Can you fish those out and reply with something I can just cut/paste into the spec? :-)
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Brian Eaton > Sent: Monday, May 11, 2009 11:52 AM > To: [email protected] > Subject: [oauth] Re: Request for new Security Considerations text > > > There were two others in my first note on this thread, one on UI > redress, another on automated repeat approvals. > > On Mon, May 11, 2009 at 11:45 AM, Eran Hammer-Lahav > <[email protected]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
