The key challenge for a client-side CSRF prevention mechanism is to distinguish malicious from non-malicious cross-origin requests. Here, illustrates the difficulty of this distinction by describing some attack scenarios and some important non-malicious scenarios that intrinsically rely on cross-origin requests.
Classic CSRF. It is shown here as a classic CSRF attack. In steps 1–4, the user establishes an authenticated session with site A, and later (steps 5–8) the user opens the malicious site E in another tab of the browser. The malicious page from E triggers a request to A (step 9), the browser considers this request to be part of the ongoing session with A and automatically adds the necessary authentication and session information. The browser internally maintains different browsing contexts for each origin it is interacting with. The shade of the browser-lifeline in the figure indicates the origin associated with the browsing context from which the outgoing request originates (also known as the referrer). Since the attack request originates from an E browsing context and goes to origin A, it is cross-origin.
For the attack to be successful, an authenticated session with A must exist when the user surfs to the malicious site E. The likelihood of success can be increased by making E content-related to A, for instance, to attack a banking site, the attacker poses as a site offering financial advice.
Link Injection. To further increase the likelihood of success, the attacker can inject links to E into site A. Many sites, for instance, social networking sites, allow users to generate content that is displayed to other users. For such a site A, the attacker creates a content item that contains a link to E.
Here shows the resulting CSRF scenario, where A is a social networking site and E is a malicious site. The user logs into A (steps 1–4), opens the attacker injected content (steps 5–8), and clicks on the link to E (step 9) which launches the CSRF attack (step 13). Again, the attack request is cross-origin.
NON-MALICIOUS CROSS-ORIGIN SCENARIOS
CSRF attack requests are cross-origin requests in an authenticated session. Hence, forbidding such requests is a security countermeasure. Unfortunately, this also breaks many useful non-malicious scenarios. We illustrate two important ones.
Payment Provider. Third-party payment providers such as PayPal or Visa 3D-secure offer payment services to a variety of sites on the Web. The figure shows the scenario for PayPal’s Buy Now button. When a user clicks on this button, the browser sends a request to PayPal (step 2), which redirects the user to the payment page (step 4). When the user accepts the payment (step 7), the processing page redirects the browser to the dispatch page (step 10), which loads the landing page of the site that requested the payment (step 13). Note that step 13 is a cross-origin request from PayPal to A in an authenticated session, for instance, a shopping session in Webshop A.
Central Authentication. The majority of interactive Websites require some form of authentication. As an alternative to each site using its own authentication mechanism, a single sign-on service (such as OpenID or Windows Live ID) provides a central point of authentication. An example scenario for OpenID authentication using MyOpenID is shown. The user chooses the authentication method (step 1), followed by a redirect from the site to the authentication provider (step 4). The authentication provider redirects the user to the login form (step 6). The user enters the required credentials, which are processed by the provider (step 10). After verification, the provider redirects the browser to the dispatching page (step 12), which redirects to the processing page on the original site (step 14). After processing the authentication result, a redirect loads the requested page on the original site (step 16). Again, note that step 16 is a cross-origin request in an authenticated session.
These scenarios illustrate that mitigating CSRF attacks by preventing cross-origin requests in authenticated sessions breaks important and useful Web scenarios. Existing client-side countermeasures against CSRF attacks either is incompatible with such scenarios or require user interaction for these cases.