Dangers of CSRF and XSS

Let's begin with a CSRF attack, simply because it takes the least amount of effort to perform and many applications are vulnerable to it. Consider an application such as a bulletin board or a blog that allows the user to embed images into their messages via the use of the <img> tag or the BBcode equivalent [img] tag. To those unfamiliar with BBcode, it is a set of formatting tags, very similar to HTML, but intended to provide a limited subset of text formatting attributes.

Rather than supplying a genuine image, the URL will actually link to some page on the site where a GET request executes an action, for example http://foobar.com/admin/delete_msg=1. When the user loads the page, the browser will try to open the image. This will inadvertently execute a command that removes the message with an ID of 1. This will not work for all users, but we only need to perform the action once. Vulnerable users are those who are logged in at foobar.com and have an authentication cookie, and thus have the necessary credentials to perform a given action.

How mindless web browsers help the intruder

To make matters worse, old versions of Internet Explorer and other browsers execute and render entire web pages hidden in images. If the URL points to an HTML file, the browser renders and executes that page, retrieving all of its components as well. This is particularly dangerous as the page can contain an extensive JavaScript code block, which can be used to reference and modify the content of the original page by referencing its content via window.opener.

This particular abuse was one of the earliest CSRF attacks, used by scammers trying to drive traffic to their sites by getting to the top of various link aggregators. The scammers tended to embed image widgets on their pages linking to aggregator sites, thus making each visitor effectively perform a request to the site. This in turn would significantly elevate their "ping-back" statistics, getting them to the top of the list quickly. This scam is still out there, but it relies on linking directly to a URL assigned to each site, with the purpose of linking back to the tracker. For example, foobar.com may have been assigned a URL as http://tracker.com/?sid=1234, so the site's operator can simply embed this URL on various sites (including his own), making each user loading the page visit his page. In effect, foobar.com would be sending a lot of traffic to tracker.com. Fortunately, because only one URL is loaded, in most cases a simple HTTP Referrer check will reveal the scam.

Another attack is mostly an attempt to break the site's layout. For example, the trickster could use an image that is small in file size but has large dimensions, thus ensuring it takes up the entire screen, pushing all other content off the page. For example, a GIF image with massive dimensions of 2000 by 2000 pixels can take a mere 3786 bytes and is sure to take up all of the screen space, no matter how large your monitor is. But this is not really a hack per say, more an annoyance than anything else.

Now you may be thinking: "My application is smarter: rather than allowing arbitrary image links, it uses the PHP function getimagesize() (or equivalent) to validate each image to ensure it is really an image of acceptable size and dimensions."