Why do we need any link? Why isn't it enough to just say 'Clickjacking' and let people find out more info on their own.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Brian Eaton > Sent: Monday, May 11, 2009 1:41 PM > To: [email protected] > Subject: [oauth] Re: Request for new Security Considerations text > > > Wikipedia is about as formal as you're going to get for the moment: > http://en.wikipedia.org/wiki/Clickjacking > > On Mon, May 11, 2009 at 1:27 PM, Eran Hammer-Lahav > <[email protected]> wrote: > > > > We can't really link to a website from the spec, only to other > documents. Any other ideas to replace your reference to [1]? > > > > EHL > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > Behalf > >> Of Brian Eaton > >> Sent: Monday, May 11, 2009 12:59 PM > >> To: [email protected] > >> Subject: [oauth] Re: Request for new Security Considerations text > >> > >> > >> Service providers should protect the approval process against > >> "clickjacking" (sometimes called UI redress) attacks. > >> As of the time of this writing, no complete defenses > >> against clickjacking are available. A survey of attacks and > defenses > >> may be found at [1]. Service providers can mitigate > >> the risk of UI redress attacks through the following techniques: > >> - javascript frame busting > >> - javascript frame busting, and requiring that browsers have > >> javascript enabled on the approval page > >> - browser-specific anti-framing techniques > >> - requiring password reentry before issuing OAuth tokens > >> > >> > >> Automatic Repeat Approvals > >> > >> Some service providers may wish to automatically approve OAuth > access > >> requests from consumers who the user has already indicated they > trust. > >> For example: > >> Consumer sends request token request > >> User is redirected to service provider approval URL. > >> Service provider detects that user has approved previous access > >> requests from this consumer. > >> Service provider does not prompt the user for approval, and instead > >> redirects the user back to the consumer. > >> Consumer fetches approved access token for user. > >> > >> Automatic repeat approvals create additional security risks by > >> removing the need for a consumer to possess an access token to fetch > a > >> user's data. If no automatic repeat approval is used, the attacker > >> must use social engineering to convince the user to approve access. > >> Once automatic approvals are implemented social engineering is no > >> longer necessary. Compromise of the consumer secret is sufficient > to > >> gain automatic access to a user's data. > >> > >> Service providers can mitigate the risks associated with automatic > >> repeat approval flows by limiting the scope of access tokens > returned > >> for such approvals. > >> > >> > >> [1] > >> > http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_( > >> UI_redressing) > >> > >> > >> On Mon, May 11, 2009 at 11:55 AM, Eran Hammer-Lahav > >> <[email protected]> wrote: > >> > > >> > 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 -~----------~----~----~----~------~----~------~--~---
