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
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.
to post comments)