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 <e...@hueniverse.com> wrote: > > Cool. Are there any other new security consideration sections we need to add, > or is this the only one? > > EHL > >> -----Original Message----- >> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf >> Of Brian Eaton >> Sent: Friday, May 08, 2009 3:39 PM >> To: oauth@googlegroups.com >> Subject: [oauth] Re: Request for new Security Considerations text >> >> >> I like it. >> >> On Fri, May 8, 2009 at 3:35 PM, Darren Bounds <dar...@cliqset.com> >> 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 <bea...@google.com> >> wrote: >> >> >> >> On Fri, May 8, 2009 at 3:16 PM, Darren Bounds <dar...@cliqset.com> >> 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 >> > dar...@cliqset.com >> > >> > > >> > >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
