Cross-Site Request Forgery (CSRF)

In this article..
What is Cross-Site Request Forgery?
How does CSRF work?
Impact of CSRF attack
Protecting against CSRF attacks

What is Cross-Site Request Forgery?
Cross-site request forgery (also referred to as CSRF) is an browser based attack where an attacker sends requests to 3rd party sites on behalf of the victim and tries to perform unauthorized actions.

How does CSRF work?
An attacker may trick a user into visiting a malicious page. This can be done by either injecting the attack code into legitimate sites or by setting up a website and promoting it on search engines. For example, the website might purport to contain information on, say, secure coding. When some one searches for secure coding guidelines, this website might be one of the search results that the user visits.

The malicious page, in addition to other information, might contain a link to a different site, say in an image tag. When the browser tries to get the image from that site, it sends any cookies associated with that site as part of the request. If the user is logged in (or if the site automatically logs in the user based on information in the cookie), the request may be processed by the server as though the victim made the request.

In this case, the attacker would have successfully performed an action on the 3rd party website without even having the login credentials of the victim and without the victim knowing about it.

Here is the sequence of steps for the attack:

  1. The user (victim) visits a malicious site (www.malicioussite.com), either from a search result, clicking on a link in an email or by directly going to the site.
  2. The page on the site loads, but also contain a link to the user’s bank “change password” page.
    ...
    <img src="www.bank.com/accounts/changepassword.jsp?oldemail=victim@domain.com&newemail=attacker@attackersdomain.com" />
    ...

    When the page loads, the browser tries to load the image and makes a request to www.bank.com and appends any cookies that are present on the system (login credentials/session ids) to the request.
  3. If the user is logged in already, the server recognizes the session id and tries to act on the request. If not, and the server allows automatic logins based on information stored in the cookie, the user is logged in and the server tries to act on the request.
  4. If that request is what is used to change user’s email ids, then the server performs the action transparently.
  5. The attacker now goes to the site and initiates the “forgotten password” process. The server sends an email to the email address on record, which is now the attacker’s email id.
  6. The attacker resets the password and logs in to the user’s account, completing a successful attack

This scenario, while simplistic with a lot of assumptions, does work in real life with many web applications. Recently, a CSRF vulnerability was discovered in Joomla where an attacker could create new users with admin permissions.

Impact of CSRF attack
As the name indicates, this is a request forgery attack in which the attacker impersonates another legitimate user in targeting the victim website. Depending on the functionality provided by the web application that is being targeted, the impact can vary from annoyances to administrative control for the attacker.

Protecting against CSRF attacks
While CSRF attacks are primarily due to vulnerabilities in the way the web application is designed/coded and should be fixed by the developer, users can protect themselves by logging out of applications before going to another website.

Developers can consider the following to protect their application from CSRF attacks:

  • Use page level tokens that are changed with every request. These tokens are one time tokens that are not the same as the session id.
  • If other session protection measures are in place, then the tokens can be per session instead of per request.
  • A variation of the previous method is to just use the session-id and place it in a URL parameter. This will be in addition to the session id that is placed in the cookie by PHP. If the website is vulnerable to session fixation attacks, then this method will not work.
  • Force the user to confirm sensitive actions by authenticating them again. For example, banks might require the user to enter the password again when they do an account transfer.
  • OWASP has a project to develop filters for different platforms that will protect against CSRF.