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 -~----------~----~----~----~------~----~------~--~---
