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