Preventing cross-site request forgery (XSRF, CSRF, aka one-click attack)
18 Jan 2007
The XSRF attack exploits the stateless nature of HTTP and your web application. In its essence, an attacker can trick you into taking an action against a site. To do so you would just need to visit the attacker's site or fall victim to some phishing attack, etc. Here's an example. Consider a web application that sells things, call it Amazonians. You have a user profile page there, where you can change your account's email address. This is the email address where your password is sent when you click "forgot password." When you use this page to set your email address, it's a simple HTTP POST and the only value sent up is your password wrapped in SOAP, JSON, whatever. In order for this request to succeed however, you need a valid cookie.
Here's the attack. You visit evil site. Evil site prepares the above request to change your email address to something that evil site now controls. By visiting evil site, your browser is automatically redirected (by virtue of a link or an XmlHttpRequest) to make that request to Amazonians. Since your browser has valid cookies for the website, the request succeeds, and now evil site owns your account.
Okay so how do we prevent this? Some options are:
a) Amazonians require that you type in your password when making the request to change your email address. Unless evil site can trick you into entering your Amazonian password, then the request would fail.
b) Amazonians require that you enter a captcha. Same as above.
c) Amazonians generates a one-time, unique random value that is sent to you when the page is requested. This value is tied to your session and required to be sent up in the Postback. Problem with this technique is that some cross-domain browser bugs may be used by the attacker to get this value. Consider the Internet Explorer mhtml:// bug.
The key to preventing the XSRF attack in the face of such browser bugs, is to really analyze the web app and understand which calls are most critical and require a solid mitigation. Obvious places include:
Here's the attack. You visit evil site. Evil site prepares the above request to change your email address to something that evil site now controls. By visiting evil site, your browser is automatically redirected (by virtue of a link or an XmlHttpRequest) to make that request to Amazonians. Since your browser has valid cookies for the website, the request succeeds, and now evil site owns your account.
Okay so how do we prevent this? Some options are:
a) Amazonians require that you type in your password when making the request to change your email address. Unless evil site can trick you into entering your Amazonian password, then the request would fail.
b) Amazonians require that you enter a captcha. Same as above.
c) Amazonians generates a one-time, unique random value that is sent to you when the page is requested. This value is tied to your session and required to be sent up in the Postback. Problem with this technique is that some cross-domain browser bugs may be used by the attacker to get this value. Consider the Internet Explorer mhtml:// bug.
The key to preventing the XSRF attack in the face of such browser bugs, is to really analyze the web app and understand which calls are most critical and require a solid mitigation. Obvious places include:
- anywhere password or account information can be changed
- anywhere data or records can be added, modified or deleted