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 <dar...@cliqset.com> 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 <bea...@google.com> 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 <dar...@cliqset.com> 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 <bea...@google.com> 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 <e...@hueniverse.com> >>>> 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 >>> dar...@cliqset.com >>> >>> > >>> >> >> > >> > > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
