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