OWASP Vulnerability #8 – Cross-Site Request Forgery (CSRF)

 

Computer crime concept.Continuing with the discussion of the OWASP Top 10 Web Vulnerabilities, this post will look at number 8: cross-site request forgery. This particular vulnerability is difficult for many people to understand, but can be quite common in web applications. Because of its prevalence, Clearent has had to digest and understand this vulnerability in order to build a secure, PCI-compliant payments platform.

What is Cross-Site Request Forgery?

Cross-Site Request Forgery (CSRF) is a vulnerability where a website accepts requests from an agent that were not originated by an authorized user. This attack is best understood with an example. Let’s say a user is logged into their bank’s online banking website and while authenticated, the user visits another site by creating a new tab in the browser. The other site visited has a hidden link that sends a request to the user’s bank, initiating a transfer request to a bad guy’s bank account. The malicious request uses the cookies and session data of the authenticated user in the request, allowing the request to succeed. In this example, the bank site is susceptible to a Cross-Site Request Forgery.

Quite often, people confuse this vulnerability with #3 on the list, Cross-Site Scripting (XSS). I believe the confusion arises because many attacks that perform a cross-site request forgery start by embedding a malicious link into a different site by exploiting the XSS vulnerability. Although these two vulnerabilities are related, they are different and have different solutions. (I will cover XSS in more detail in a future post.)

How to Mitigate the Risk of Cross-Site Request Forgery:

The cross-site request forgery vulnerability is very scary, but is easy to detect and has some straight-forward solutions. There are two main approaches to mitigate this risk from a technical stand point.

  1. A unique token can be included in every request to a particular website. This token is usually embedded as a hidden field in a form so that it is submitted along with a valid request. If a valid token isn’t present, a given request is not fulfilled by the web server. Many modern web application frameworks can include this token automatically for every form submission.
  2. Another technical solution that can be employed is to prompt a user to authenticate before a request is completed that changes data. This is arguably the most secure approach, but tends to frustrate users and muck up a user’s experience with a site. Even though this approach is heavy-handed, it may be more appropriate for some operations.

Cross-site request forgery is a vulnerability that appears quite often. Thankfully, developers can implement a straight-forward solution to maintain a secure application and prevent forgery from happening.