I would call what you've described (knowing the user who initiated the OAuth dance is same user who completed it) as mixed binding, not late binding, due to the fact a successful negotiation is dependent on information from both the start and end of the dance.
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. Do you feel differently? Darren On Fri, May 8, 2009 at 5:24 PM, Brian Eaton <[email protected]> wrote: > > I don't follow this bit: "by avoiding early binding (Section > INSERT_EARLY_BINDING_SECTION_ID)" > > How do you propose to avoid early binding if not by verifying that the > entity who begins an OAuth negotiation is the same entity who > completes it? > > On Fri, May 8, 2009 at 2:02 PM, Darren Bounds <[email protected]> wrote: >> >> [ Made slight changes to the attack value prop and the prevention >> recommendation. ] >> >> 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 may prevent CSRF attacks on OAuth callback URLs >> by avoiding early binding (Section INSERT_EARLY_BINDING_SECTION_ID) or >> by ensuring the entity who begins an OAuth negotiation is the same >> entity who completes it. >> >> >> >> On Fri, May 8, 2009 at 3:11 PM, Brian Eaton <[email protected]> wrote: >>> >>> [trimmed a bit of language that seemed redundant, added a bit to >>> explain about attacks on the OAuth callback, but I don't really love >>> the sentences I wrote about that.] >>> >>> 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 an >>> access token without the consent of the user. 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 who begins the OAuth flow is the same >>> as the user who completes the OAuth flow. >>> >>> >>> >>> On Fri, May 8, 2009 at 12:03 PM, Darren Bounds <[email protected]> wrote: >>>> >>>> Brian, any thoughts on the CSRF language I submitted in my previous >>>> email? Tried to keep it short and generic yet informative. >>>> >>>> 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. Unlike cross-site scripting (XSS), which exploits the >>>> trust a user has for a particular site, CSRF exploits the trust that a >>>> site has for a particular user. >>>> >>>> CSRF attacks on OAuth can be viewed as particularly valuable as they >>>> often offer an attacker persistent access to protected OAuth resources >>>> via the theft of Access Token material. It is because of this that >>>> Service Providers implementing OAuth should strongly consider best >>>> practices in CSRF prevention at all OAuth endpoints. >>>> >>>> References: >>>> http://en.wikipedia.org/wiki/Cross-site_request_forgery >>>> http://www.owasp.org/index.php/Cross-Site_Request_Forgery >>>> >>>> >>>> On Fri, May 8, 2009 at 2:52 PM, Brian Eaton <[email protected]> wrote: >>>>> >>>>> Consumers should XSRF protect the callback process. >>>>> [assuming others will fill in detail here] >>>>> >>>>> Service providers should XSRF protect the approval process. >>>>> [assuming others will fill in detail here] >>>>> >>>>> [I really don't think we should recommend particular XSRF prevention >>>>> mechanisms, because that's an area of active research. A link to an >>>>> authoritative description of the attack would be appropriate.] >>>>> >>>>> >>>>> Service providers should protect the approval process against >>>>> "clickjacking" (sometimes called UI redress) attacks. [link to >>>>> authoritative reference would be good, I think >>>>> http://code.google.com/p/browsersec/wiki/Part2#Arbitrary_page_mashups_(UI_redressing) >>>>> is good.] As of the time of this writing, no complete defenses >>>>> against clickjacking are available. Service providers can mitigate >>>>> the risk of UI redress attacks through the following techniques: >>>>> - frame busting >>>>> - frame busting, and requiring that browsers have javascript >>>>> enabled on the approval page >>>>> - 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. >>>>> >>>>> >>>>> Cheers, >>>>> Brian >>>>> >>>>> On Wed, May 6, 2009 at 1:43 PM, Eran Hammer-Lahav <[email protected]> >>>>> wrote: >>>>>> >>>>>> We have identified a few new attack vectors since the spec was >>>>>> originally written and would like to address them in the Security >>>>>> Consideration section. Please reply with proposals for such texts. >>>>>> Ideally we can reach some consensus on these by Fri, but if not, we can >>>>>> add it a bit later since it doesn't affect the protocol directly. >>>>>> >>>>>> EHL >>>>>> >>>>>> > >>>>>> >>>>> >>>>> > >>>>> >>>> >>>> >>>> >>>> -- >>>> darren bounds >>>> [email protected] >>>> >>>> > >>>> >>> >>> > >>> >> >> >> >> -- >> darren bounds >> [email protected] >> >> > >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
