More often than not, when people think of a hacker, they think of someone technologically infiltrating a network and stealing mass amounts of sensitive information sitting behind it. In actuality, hackers tend to employ methods that take advantage of individual users, often in tandem with some form of social engineering.

How does CSRF work?

During a cross-site scripting (XSS) attack, a user can be tricked into giving up sensitive information about themselves and their account. Rather than stealing information through the exploit itself, the intent of a CSRF attack is to make a change to either the user or the application. This is often achieved by sending a sensitive URL and/or code snippet via email (or other means) for the intended victims to execute an unintended request, such as changing a user’s email address to one the hacker can access. If an admin account is targeted, a hacker may even gain control of an entire website or application.

Is my site vulnerable to CSRF?

To test for this vulnerability, you’ll need to locate a URL that makes a restricted change to your user or application, meaning it can only be executed while logged in. In most cases, these are URLs that would only be loaded by clicking a button rather than visiting them directly.

As an example, consider that a website has an option to delete your user account. When you click the delete button, the site loads the following URL:

This page checks which user you’re logged in as and deletes the account, as requested. If that URL works when loaded directly rather than ONLY when the button is clicked, then it is vulnerable to a CSRF attack.

It is important to keep in mind that CSRF attacks have other vectors too, such as forms automatically submitted via JavaScript and other automated code that can be embedded in invisible images. While the test cases are many, the prevention methods are generally the same.

How can I prevent CSRF?

Given the common example above, the challenge is to ensure that the URL in question cannot be loaded directly, but rather only by clicking the corresponding button within the application. This is usually achieved by checking the URL referrer, contained in the request headers. When a button is clicked, the referrer in the header will be the URL of the page that contains the button itself. In the case of loading the URL from an email or by entering it directly into a browser, the referrer will be different or there won’t be one at all. Essentially, a check to ensure the referrer is what you expect can prevent these forged requests from being processed.

How can SiteLock help?

SiteLock has developed an automated website scanning service designed to detect vulnerabilities like CSRF. The scan will go through an entire site, just as a hacker might, with the intent of finding any CSRF vectors to be exploited. If a problem is found, the site’s owner is notified and prompted to take further action. SiteLock’s Expert Services team offers application-hardening services for these situations that tend to require custom remediation.

Coming from a different angle to solve this common problem, SiteLock offers what is called a Web Application Firewall (WAF). The WAF is designed to scan and filter all incoming website traffic. This is achieved by referencing libraries of IP addresses with poor reputations and readily available examples of CSRF methods, among other things. The end result is that undesirable traffic is kept out while the intended audience views a secure and clean site each and every time.

Consequences of a CSRF attack

A CSRF attack can have wide ranging implications from individual user account hijacking to admin account access that can compromise an entire site or application. When we consider the example above, wherein an account is unintentionally deleted, the implications can be even worse. Consider a hacker who first uses a SQLi attack to obtain the email addresses of all a site’s users and then sends each one a fraudulent email with the CSRF attack embedded in it. There’s really no telling how many accounts will be deleted by mistake!

In addition to stealing user data, a website with a CSRF vulnerability may find itself shut down through a number of different channels. It’s not at all uncommon for web hosts to get complaints about hacked sites, which will in turn cause them to suspend the site and site owner’s account. You may also find that antivirus applications have caught on to the problem and will alert users when a site is dangerous and should be avoided. And last, browsers such as Google Chrome scan sites for these problems and when found, they will alert their users that a site is unsafe and should be avoided. All of these possibilities can result in quickly eroding a site’s credibility.

To read more about SiteLock website scanning services, click here.

To read more about the SiteLock WAF, click here.