Sounds fine to me. On Mon, May 11, 2009 at 1:58 PM, Eran Hammer-Lahav <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
