Cross Site Request Forgery (CSRF).

What is Cross Site Request Forgery?

Cross Site Request Forgery (CSRF) is a type of security attack in which an attacker tricks a victim into executing an unintended request that changes the victim’s state of data, without  the victim’s realization.  Per OWASP, other names for CSRF include “XSRF, “Sea Surf”, Session Riding, Cross-Site Reference Forgery, and Hostile Linking”. Granted success, examples of consequences include funds transferring from the victim’s account into the attacker’s account, granting the attacker access to resources, impersonating the victim’s account etc …

Characteristics of a CSRF attack:

Below are some notes on CSRF, most of which are from OSWASP.

• CSRF attack acts on changing the victim’s state of data. The attacker does not see the response for the forged request, and so does not base attacks on the response. As such, CSRF attacks make sense if the user is authenticated.
• The type of the request (GET, POST, PUT, DELETE ) does not matter.  For example, the attacker can use javascript to post a request or an embedded URL for a GET request.
• Https does not protect against CSRF in anyway, Assuming the victim has been authenticated, and the browser includes cookies when sending requests (usually browsers do this by default), it does not matter if the browser sends the request via http or https. From the application perspective, all it know is the request comes from the victim who has been authenticated.
• Other measures that are not effective in protecting against CSRF, as stated by OWASP include: URL Rewriting, multi-step transactions, using a secret cookie.

Example:

Usually, an attacker carries out a CSRF attack through the use of social engineering, malicious scripts, an iFrame etc … Let’s consider an example.

Bob usually purchases merchandises through a popular, yet insecure online retailer – XYZInc. Knowing about XYZInc’s vulnerability, the attacker who owns the malicious website which Bob also visits frequently, includes a malicious javascript which upon execution, submits a request to purchase an electronic gift card and sends to the attacker’s email. Bob has been logged into XYZInc and has not logged out of his account.  When Bob visits the attacker’s website, the javascript loads automatically to submit  the form, along with the browser’s cookie which contains Bob’s session with XYZInc. Without Bob’s realization, Bob has executed the request  to purchase the gift card that gets sent to the attacker.

<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://xyzinc.com/purchase?type=egift", true);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.send(JSON.stringify({
amount: 1000,
email: 'attackeremail@yahoo.com'
paymentMethod: 'CardOnFile' 
}));
xhr.onload = function() {
console.log("Successfully purchased gift card.")
}
</script>
}

How to protect against a CSRF attack:

The standard way of protecting against  CSRF is via an Anti-CSRF token. The idea is that a web application  should always send back the token to a user’s browser (often when generating html page for the browser to display, or upon successful authentication). When the browser submits a request to the application, the application makes sure the request contains the token, and that token matches the one the application sent. If the checks fail, then the request fails. A proper implementation using Anti-CSRF token follows these rules:

• The token should be cryptographically secured. An attacker should not be able to guess the token.
• Invalidated after sometime and after the user has logged out.
• The Anti-CSRF token should not be able to access by any host other than the one
• Access to the token is restricted to only the intended host via HTTP access control (same origin policy). Care should be taken when using CORS headers to allow other origins access.

References: