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 <e...@hueniverse.com> 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: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf >> Of Brian Eaton >> Sent: Monday, May 11, 2009 12:59 PM >> To: oauth@googlegroups.com >> 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 >> <e...@hueniverse.com> 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: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On >> Behalf >> >> Of Brian Eaton >> >> Sent: Monday, May 11, 2009 11:52 AM >> >> To: oauth@googlegroups.com >> >> 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 >> >> <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 -~----------~----~----~----~------~----~------~--~---
