What are the dangers of cross-site request forgery attacks (CSRF)?

Many cross-site attacks involve attackers posting content on a shared, public site that other users read with their browsers. For example, consider a news site that allows people to post comments on the news articles they host, or an auction site that lets people rate a given seller. One user is posting content that many other users might read, a common function in today's webified world. Suppose that site doesn't filter input from users, allowing any user to post in the comment fields on their sites, including browser scripts and HTML.

If an attacker posts evil content on a site, and a user reads that content, it will force the user's browser to do something. In an XSS attack, the attacker's content is a browser script (often JavaScript) that runs inside the user's browser, performing certain functions, such as engaging in transactions on the target site. A script running inside the victim's browser can do anything on the site from which the script is delivered. In our news example, when the malicious browser script posted by a hacker is running, it can do whatever a user can do on the site, such as posting a phony comment on a news story, posing as the user. In the auction example, the script could actually bid on an auction of the attacker's choosing. By merely reading the attacker's comment on a given seller, the victim's browser has automatically bid on an auction! Ouch.

XSS emphasizes scripts posted as content, but not XSRF. To understand XSRF, keep the news site and auction site examples in mind, but also consider another site, such as one that offers online banking. Suppose our victim uses online banking, which authenticates the user and then sets a session cookie in the user's browser to track that user through a series of transactions. Now, let's say that this user, with the bank's cookie set in his or her browser, uses that same browser in another window to access the news or an auction site. On the news and auction sites, the attacker hasn't posted a browser script, but instead has posted some HTML content, such as image tags, that refer to some page on the bank site. For example, the attacker may post content on the auction site with something of the form:

<img src="http://bank.counterhack.net/transfer.php?amount=10000&recipient=badguy=> 

When the victim's browser reads this image tag on the news or auction site, it will try to fetch this "image" as it renders the news or auction page. But, in doing so, it will actually send an HTTP request to the bank (which, in this contrived example is bank.counterhack.net, a fictional site in my own counterhack.net domain). The HTTP request will ask the bank to invoke a function called transfer.php, which transfers funds between accounts. It will move $10,000 from the victim's account to the hacker's account.

This all assumes, of course, that the bank has a PHP function called transfer that is invokable in this manner via a URL. If the bank has such a function, the attacker can carefully craft a URL to invoke it, place references to that URL in image tags (or other tags) on news sites, auction sites, blogs, photo sharing sites, video sites and so on. If a user is logged onto the bank with a cookie set, the user's browser, upon reading the content from the news or auction site, will engage in a transaction with the target bank. As far as the bank is concerned, this is a legitimate transaction, because the browser passes the cookie for the banking session back with the HTTP request. The bottom line here is that XSS focuses on browser scripts, whereas XSRF focuses on content that contains URLs that reference other sites, making the browser go to those sites and do business of the attacker's choosing.

Now, back to your question: are XSRF attacks more dangerous than other cross-site attacks? Both XSS and XSRF attacks are equally dangerous. Either could seriously mess up your day, draining your bank account or causing other major problems in your life. Thus, it's a tie, and we need to defend against both diligently.

What can we do to stop them? The defenses are split up based on the three parties associated with this attack: the content hosters (the news or auction site), the e-commerce site (the bank) and users. Content hosters must diligently filter user input to remove elements that are meaningful in scripts and even in HTML tags. Unfortunately, these tags are highly desirable for users who want to customize the appearance of content they post on sites and include references to images stored elsewhere. We could disallow such references to be posted, but that's awfully restrictive, and isn't a common practice.

E-commerce sites like banks and merchants should consider transitioning your session-tracking mechanisms from cookies to a dynamically generated session token that is included as an HTML hidden form element, changing from page to page as a user accesses the application. That way, it's a lot harder for an attacker to get a handle on a victim's session, which can set the stage for all kinds of Web-based attacks. For XSRF in particular, a bank app built in this way will have no cookie to be passed back to the bank when the browser tries to fetch the image referred to on the third-party site, making the bank's session-checking code fail and thwarting the XSRF attack.

But, how about users? To avoid XSS attacks, it's wise to disable scripting altogether, or Firefox users should consider a great plug-in for the browser called noscripts. This add-on lets you stop scripts or block potentially malicious ones. Furthermore, to thwart XSRF attacks, consider using two different browsers to separate your day-to-day Web surfing from your e-commerce transactions. Use one browser to do online banking and shopping, and another browser for routine Web surfing and news reading. That way, if you do stumble upon an XSRF attempt, the bad guy won't be able to make your Web-surfing/news-reading browser really do anything interesting on your e-commerce sites.

For more information: