Cross-site request forgery

Cross-site request forgery (CSRF or XSRF) is yet another web application flaw that can have serious impacts. By exploiting the trust that the targeted site has in a logged-in user, usually encapsulated in a cookie, CSRF can perform actions on behalf of that user, without any indication that the action took place. It shares many traits with its better-known sibling, cross-site scripting (XSS), but, unlike a site targeted via XSS (for login spoofing or cookie stealing for example), the target web site can make changes to avoid CSRF.

A CSRF attack targets a specific web site, one that requires credentials to perform actions. Financial and shopping sites are common targets, but as described in last week's article on this page, home routers and similar equipment are also targets. Another popular target is sites like Digg, where users vote on particular stories to increase their popularity; an attacker can drive more traffic to a site of their choosing by using a CSRF exploit to add votes.

The exploit itself is typically contained in an <img> tag or form submission, with Javascript sometimes used to hide the form submission. The URL used causes some kind of side effect on the target website as long as a properly authenticated cookie is delivered with the request. For example, if LWN had a voting system, a tag like the following could perform a CSRF exploit:

    <img src="http://lwn.net/vote?type=y;story=some_lame_story_URL" width=0 height=0>

When the browser goes to fetch that "image", it helpfully sends along any cookies that correspond to the domain; if the vote application wasn't written correctly, anyone viewing the web page - and who was also logged-in to LWN - would add a vote for the story. There would be no indication that anything had happened, other than possibly a fleeting notice in the browser noting a connection to LWN.

Getting the user to visit the page with the CSRF is done in the usual way, via a link in email, instant message, or on another web page. CSRF does not require inserting code into the vulnerable website, which is the hallmark of XSS; instead it exploits the target from afar. The link the victim follows will not in any way indicate the target site.

There are a few things that web application programmers can do to eliminate CSRF problems; the basic idea is not to perform actions solely based on a proper cookie. Just as some non-internet authentications require two forms of identification, web applications should do the same. The second identification should come from something other than the cookie, something that can be known only by a properly authenticated user.

Two basic techniques are used, random form tokens or re-authentication. For sensitive operations, the best protection is to require the user to provide their credentials (username and password for example) before performing the action. This can be cumbersome, so, for less sensitive actions, hidden fields with random names and values can be inserted into each form, associated with a particular session, and checked on form submission. This isn't completely secure, as the values might be guessed, but with sufficient randomness, it is good enough for many operations.

It should be noted that preventing CSRF requires that all XSS problems are removed first. An XSS flaw can be used to retrieve the form, then grab the random tokens before submitting the CSRF request. XSS may also be able to spoof the user into entering their credentials, which would allow the CSRF to bypass re-authentication as well.

CSRF has been called the "sleeping giant" of web application security flaws, because it has yet to be exploited widely. It is only a matter of time, web programmers should be making the changes needed to ensure that their sites are not vulnerable.

---

(Log in to post comments)

Even if the app only modifies data in response to a POST, it is still very trivial for a site
to include a hidden form with automatic submission thanks to JavaScript.

The hidden magic numbers in form submissions is one approach to solving this I never thought
of.

I've just relied on the HTTP referer header: sans a bug in the user's browser, sites and
scripts cannot forge this header.  Someone could trivially write their own utility or program
which performs HTTP requests with a forged referer (curl and wget both support setting this to
arbitrary values), but then they wouldn't have the proper authentication cookie.

Not the most robust solution nor all that ideal in theory, but it's Good Enough(tm) in
practice.

I agree that you need further measures to protect against malicious webmasters, but they are a
small part of the problem.  The larger part of the problem is that anybody can put <img
src="whatever"> into a forum post (including this one) which causes a simple GET request.  If
your application has side effects on GET requests, then it is vulnerable to this very simple
attack.

You forgot to add a <marquee>.

lol, the medium is indeed the message.

MY EYES, MY EYES!!! :D

Thank goodness for firebug.

A hidden form that automatically sends POST requests to some other site without user
intervention?  Do you have an example?  I'm just surprised that this is allowed by
Javascript's security model (as tightened up by recent browsers).

Of course I agree strongly with the grandparent; don't use GET requests for stateful
operations.  That is just asking for trouble.  I once worked in a web development shop where
the policy was that clickable links were somehow cooler than form submit buttons, so the user
management page had a 'delete' link for each user.  A customer was using a web accelerator
program that prefetches links (a perfectly allowable thing to do, provided it just GETs) and
deleted all users from the site.

Sure they can have side-effect, the quote you include says as much.

What it says is that "the side-effects of N > 0 identical requests is the same as for a single
request."

In other words, for a GET-request it should make no difference if you visit the link 1 time,
or 200 times, the side-effects should be identical. There is allowed to be a difference
between visiting the link 1+ times, and visiting 0 times.

That's NOT the same as saying there should be no side-effects.

An example: Voting for a story on Digg. If you vote yes for a certain story once, or 100
times, the result is the same: your vote is registered as a yes.

Another example: Adding a certain book to your amazon wishlist. Whether you do the relevant
GET-request once or 10 times, the side-effect is the same: that book will appear on your
wishlist. (once, not 10 times!)

So no, respecting the difference between GET and POST will do precisely nothing at all to
combat this particular vulnerability, though it would have -other- advantages.

I wrote about this previously here:

http://www.debian-administration.org/articles/465

Whilst the main diagnosis of GET/POST abuse is correct it is still possible to submit forms
via POST with a little user action.  Consider a form which is hidden and a link which has
'onClick=form.submit()' for example.

Thank you for this article, I had not seen it so clearly explained.