Unlike attacks aimed squarely at website or application operators, the goal of many Cross-Site Request Forgery (CSRF) attacks is to steal money, goods or credentials directly from a user. This does not mean that site operators should ignore CSRF code vulnerabilities, as ultimately the replacement of stolen funds, in the case of a purely monetary attack, may be the responsibility of the hosting site with the insecure code. And if the targeted user instead loses their credentials or has their password unknowingly changed, a criminal might be able to wreak havoc using that stolen identity, especially if the victim has privileged access.

CSRF attacks are fairly complex and rely on multiple layers to be successful. In other words, lots of things have to break in favor of the attacker for it to work. Despite this, they are an extremely popular attack vector because a successful attack can transfer money directly to a hacker, or set them up to be able to move about a site with impunity. If everything goes a hacker's way, the targeted user may never even know that they fell victim to an attack.

The good news is that because so much has to go right for a CSRF attack to work, there are quite a few great defensive techniques that can halt them in their tracks.

To that end, we'll discuss three key aspects of CSRF attacks:

• How they work
• Why they are so dangerous
• How you can put defenses in place to stop them cold.

How do CSRF attacks work?

Because successful CSRF attacks have the ability to directly steal money, goods or credentials from targeted users, they are popular despite the high amount of work that must go into creating them. And because they are often attempted on different platforms, over the years they have picked up a variety of names and monikers. You might hear CSRF attacks referred to as XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery or Hostile Linking. Microsoft likes to refer to them as One-Click attacks in most of its documentation. But they are all CSRF attacks, and the techniques to defeat them are identical.

A CSRF attack can happen if a user is logged into a site conducting business or doing their work. The key is that the user must be logged in and actively authenticated to a website or application. The attack is normally launched from a secondary website or an e-mail. Oftentimes attackers use social engineering techniques to trick users into clicking on a link in an e-mail that takes them to a compromised website with the attack script.

The compromised website contains a script that instructs the active browser to execute commands, normally something malicious like changing a user's password or transferring money to an account controlled by the attacker. As long as the user is authenticated, the site will think that the commands are being issued by the authorized user. Why wouldn't it? The user has already authenticated themselves and provided whatever passwords are required to access the site. They may even be located within a geofence, properly sitting at their office terminal. If they want to change their password or transfer funds, there is no reason not to believe that it's them making the request.

Breaking down the elements of the attack, it's clear why this one is so difficult to pull off for the attacker. For starters, the user must actively be authenticated with the site where the attack takes place. If an e-mail with an attack script comes in after a user has ended their browser session, or logged off, the attack fails.

The attacker is also forced to perform a lot of recon on the targeted site in order to know what scripts that site will accept. Attackers can't see a victim's screen, and any feedback from the website will go to the victim, not the attacker. Unless the attacker is able to see evidence of their attack working, such as money suddenly showing up in their account, they won't even know right away if it has been successful.

Within the difficult-but-not-impossible parameters of having the user logged in at the time of the attack and knowing what scripts the targeted site will accept, the code to execute a CSRF attack can be extremely simple, though it varies depending on the site itself.

Let's say a bank or finance application uses GET requests to transfer money, like this:

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

That code would send a request to transfer $100 to a user named NancySmith12.

But if the targeted user got an e-mail, perhaps one disguised as coming from a colleague, a CSRF attack script could be embedded in the click action:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

If the targeted user fell for the social engineering link and clicked on it while the browser session with the finance application was still open, their browser would ask the application to send $100,000 to ShadyLady15's account.

The script could even be hidden in an invisible image that the user would not see, but which could still trigger the browser to make the request, like this:

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

The result is the same. ShadyLady15 gets $100,000 without anyone detecting the attack.

Why is CSRF so dangerous?

CSRF attacks are popular today for the same reason that ransomware attacks continue to make the rounds. It puts very few hops between attackers and a victim's money. In a ransomware attack, systems are encrypted and users are extorted for money to decrypt that data. With a CSRF attack, it's even fewer steps. When they work, victims simply send money to attackers without knowing it.

Beyond direct attacks on a victim's money or a company's finances, successful CSRF attacks can be used to compromise a network using valid users. Imagine if an attacker could use a CSRF exploit to change an administrator's password. They could immediately use that password to begin stealing data, open up holes through network defenses or install backdoors.

Although it's a lot of work, and to some extent luck, a successful CSRF attack can be like winning the lottery for hackers regardless of their ultimate goal. When attacking a network, almost any other kind of attack would require months of low and slow reconnaissance, trying to keep below the radar of the SIEM and cybersecurity staff. By contrast, a single CSRF attack can skip quite a few steps along the cyber kill chain, letting them start very close to their ultimate goal.

How Do I Stop CSRF Attacks?

Unlike most vulnerabilities, with CSRF attacks the fault is not really with the code, but with an exploit that attackers have created to force a browser to make requests that a user doesn't want, and may not even know about. But they can be defeated.

One of the best methods is to have developers add a CSRF token to a user's identity whenever a new session is generated. It should consist of a string of unique and random characters and be invisible to users. Next, add the CSRF token request as a hidden field to forms that are checked by the server whenever a new request is submitted. Attackers submitting requests through a user's browser won't even know about the hidden token field, much less be able to find out what it is, so all of their requests will fail.

An even easier method, and one that does not require very much programming, is to add a Captcha challenge to anything sensitive like password change requests or money transfer orders. It can be as simple as asking a user to click one button confirming that the requestor is not a robot, or in this case, a CSRF script. Attackers won't be able to script a response to the challenge, and users who suddenly get a CAPTCHA challenge without first doing something like making a money transfer request will know that something is up. Alternatively, one-time password generation using a third party token, like a smartphone, can be used, depending on how much an organization wants to slow down work in the name of security.

Finally, though it is not ironclad, many browsers like Microsoft Edge or Google Chrome now have same-origin policy restrictions in place to block requests from anyone but the local user. Forcing users to interact with your site using the most updated versions of those browsers can help to build in another layer of CSRF security without taxing development teams at all.

Slamming the Door on CSRF

With such a high potential payout, CSRF attacks will likely never fully die, but we hope you learned why they are so persistent, and how to block them from your network for good.

For further reading, you can take a look at the OWASP Cross-Site Request Forgery Prevention Cheat Sheet, which serves as a living document chronicling this vulnerability as it evolves. If you'd really like to bolster your security knowledge, you can learn to defeat this threat and many more by visiting the Secure Code Warrior blog.

Think you're ready to put your new defensive knowledge to the test? Play around with the free demo of the Secure Code Warrior platform today.