Cross-Site Request Forgery Guide: Learn All About CSRF Attacks and CSRF Protection

Cross-Site Request Forgery (CSRF) is an attack outlined in the OWASP Top 10 whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.

Key Concepts of Cross-Site Request Forgery

  • Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.
  • The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.
  • The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

Ask A Qualified AppSec Expert

Ask in the Community

 

 

Rates of Credentials Management Flaws in Software

 

Credentials Management Flaw Rates

 

How Credentials Management Attacks Work

Credential management vulnerabilities result when developers fail to build in essential protections. This may include a failure to encrypt password data or store credentials in an easily accessible file, or it may involve the use of hard-coded passwords that allow an attacker to bypass authentication requirements. In order to pull off a credential attack, intruders might intercept insecure data or use brute force methods. In some cases, such as with hard-coded passwords, attacks can be difficult for a system administrator to detect, and fixing a flaw can prove challenging. In fact, in some cases, it may be necessary to disable a product or site entirely. A Veracode analysis of static scan data indicated that credential vulnerabilities exist in 42 percent of applications.

Attack and Defense Examples

Example 1

This is an example of unprotected storage of credentials:

Executing a CSRF Attack

In a Cross-Site Request Forgery attack, the attacker is exploiting how the target web application manages authentication. For CSRF to be exploited, the victim must be authenticated against (logged into) the target site. For instance, let’s say examplebank.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on examplebank.com but am not currently logged in, nothing happens. If I am logged in, however, the requests in the attack will be executed as if they were actions that I had intended to take.

Let’s look at how the attack described above would work in a bit more detail. First, let’s assume that I’m logged into my account on examplebank.com, which allows for standard online banking features, including transferring funds to another account.

Now let’s say I happen to visit somemalicioussite.com. It just so happens that this site is trying to attack people who bank with examplebank.com and has set up a CSRF attack on its site. The attack will transfer $1,500.00 to account number 123456789. Somewhere on somemalicioussite.com, attackers have added this line of code:

<iframe src="http://examplebank.com/app/transferFunds?amount=1500&destinationAccount=123456789">

Upon loading that iframe, my browser will send that request to examplebank.com, which my browser has already logged in as me. The request will be processed and send $1,500.00 to account 123456789.

Another Example of Cross-Site Request Forgery

I just bought a new home wireless router. Like most wifi routers, it’s configured through a web interface. The router was shipped to me with an internal IP address of 192.168.1.1. I’m having trouble configuring the router though, and fortunately the folks over at somemalicioussite.com have published a guide that shows me exactly what buttons to click in the router interface to get everything set up securely. The attackers have also set up a proxy server at 123.45.67.89 that will log all traffic that goes through it and look for things like passwords and session tokens.

As I clicked through the configuration guide, I missed the 1x1 pixel image that failed to load:

<img src="http://192.168.1.1/admin/config/outsideInterface?nexthop=123.45.67.89" alt="pwned" height="1" width="1"/>

The attackers knew that when I was reading their tutorial, I would be logged into the router interface. So they had the CSRF attack set up in the tutorial. With that request, my router would be reconfigured so that my traffic will be routed to their proxy server where they can do all manner of bad things with it.

Preventing Cross-Site Request Forgery (CSRF) Vulnerabilities

The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append CSRF tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.

Finding and Remediating Cross-Site Request Forgery (CSRF) Vulnerabilities

The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.

Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, password);

This code reads a password from a properties file and uses the password to connect to a database. Although this code will run correctly, someone with access to the config.properties file can read the value of a password. This might include an employee who uses this information to breach the system.

Example 2

This is an example of the use of a hard-coded password vulnerability in Java:

int VerifyAdmin(String password) {
if (!password.equals("Mew!")) {
return(0)
}
//Diagnostic Mode
return(1);
}

The problem with this code is that every instance of this program can be placed into diagnostic mode using the same password. Making matters worse, a binary-only distribution of the program makes it extremely difficult to change the password or disable its "functionality."

Example 3

This is an example in PHP of insufficiently protected credentials:

$user = $_GET['user'];
$pass = $_GET['pass'];
$checkpass = $_GET['checkpass'];
if ($pass == $checkpass) {
SetUserPassword($user, $pass);
}

The above code alters a user’s password. Once the code confirms that the user entered the same password twice, it provides access to the account. It doesn’t check the identity of the user to ensure that it’s the same person. This allows an attacker to take over the account.

Example 4

This is an example of a hard-coded credentials attack:

int VerifyAdmin(String password) {
if (password.Equals("68af404b513073584c4b6f22b6c63e6b")) {
Console.WriteLine("Entering Diagnostic Mode...");
return(1);
}
Console.WriteLine("Incorrect Password!");
return(0);
}

This example demonstrates how a cryptographic key is hard-coded into a string value that’s compared to the password. An attacker who views this code can compromise the system.

Veracode Can Aid in the Defense of a Credential Management Attack

Veracode Dynamic Analysis can safely, accurately, and quickly discover web application flaws, including credential management, in running web applications, in either production or pre-production environments.

Veracode Static Analysis can accurately identify credential management vulnerabilities and other flaws in your application and its third-party components and tell your developers exactly where and how to repair them, all without ever looking at the source code.

Our cloud-based products help you manage your application security program, track progress, and educate your developers on avoiding and repairing credential management and other security flaws through integrated eLearning materials.
 

Secure Coding Handbook

Get the Handbook

Questions About Application Security?

Contact Us