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