May 12, 2007 - 15:47 UTC - Tags: XSRF security
There has been a lot of writing about Cross-site request forgeries (XSRF/CSRF) lately. I've read numerous articles on how this could be used to capture home routers or create false online-banking transactions. In this post I'll discuss some techniques for protecting your website against XSRF.What is XSRF?
If you don't know what XSRF is, I suggest you read this wikipedia article
. XSRF exploits the fact that a user can reach a website (because he's behind a firewall or logged in to a site), that the attacker cannot attack directly. If the attacker can trick the user into running a malicious script, he can force the users browser to act on his behalf.A typical XSRF scenario
It is important to understand that these attacks are blind, meaning the attacker only controls the user's browser indirectly and cannot always see if the XSRF was successful or not.Protective measures
To be able to protect a web page from XSRF, the web server needs to check that the requests are legit. This means that it needs some measure to check that the request actually came from the corresponding form in the application.1. The referer header
Since the attacker does not directly control the user's browser, the referer header is actually a posibility. But some users disable the referer header because it leaks information when users click on links to other sites.2. Unique identifiers
The second option is to include a unique identifier for each user. When the user opens a form and posts it back the server, the identifier sent to the user in when opening the form, must be included when posting back. If it is different or not present, the post is rejected.
Creating unique identifiers is easy, and instead of using the session identifier directly, we can use the fact that the user has a session to help creating and checking the identifier. We can use hash-function (md5 or sha1) in combination with a timestamp and a secret password/key. We create our identifier like this:
id = hash_function(secret_key + timestamp_in_milliseconds)
The protective measure described will not apply to GET requests, only POST requests. But if you are allowing GET requests to alter data in your application, your are misusing the semantics of the HTTP verbs.Tabbed browsing and XSRF
Tabbed browsing actually makes XSRF more likely to succeed. The reasoning here is that all tabs share the same set of session cookies (session cookies are cookies that are deleted when the browser is closed), and users tend to be logged in to several sites at the same time. A malicious script in a tab, is thus more likely to succeed in performing malicious authenticated requests on behalf of the user.
Of course this is not a unique problem to tabbed browsing. When using the "File->Open new window" in IE6, the two windows would also share their session cookies. If opened from the start menu though, the new IE6 instance would be a completely separate process, and the two windows would not share their session cookies.More informationUpdate 24.05.07:
Ronald van den Heetkamp has a written an article about XSRF here