Cross site request forgery (CSRF) attack


What is CSRF?

Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.

Cross-site Request Forgery is considered a sleeping giant in the world of web application security. It is often not taken as seriously as it should even though it can prove to be a stealthy and powerful attack if executed properly. It is also a common attack, which is why it has secured a spot on the OWASP Top 10 list several times in a row. However, an exploited Cross-site Scripting vulnerability (XSS) is more of a risk than any CSRF vulnerability because CSRF attacks have a major limitation. CSRF only allows for state changes to occur and therefore the attacker cannot receive the contents of the HTTP response.

A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft—including stolen session cookies.

CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.

How does it work?

  • It works only if the potential victim is authenticated.
  • An attacker can enter into a website by bypassing the authentication process using a CSRF attack.
  • CSRF attacks come into use, in the scenarios where a victim having additional rights performs some action and others can’t access or perform these actions. For eg, online banking.

How Are CSRF Attacks Executed

There are two main parts to executing a Cross-site Request Forgery attack. The first one is tricking the victim into clicking a link or loading a page. This is normally done through social engineering and malicious links. The second part is sending a crafted, legitimate-looking request from the victim’s browser to the website. The request is sent with values chosen by the attacker including any cookies that the victim has associated with that website. This way, the website knows that this victim can perform certain actions on the website. Any request sent with these HTTP credentials or cookies will be considered legitimate, even though the victim would be sending the request on the attacker’s command.

When a request is made to a website, the victim’s browser checks if it has any cookies that are associated with the origin of that website and that need to be sent with the HTTP request. If so, these cookies are included in all requests sent to this website. The cookie value typically contains authentication data and such cookies represent the user’s session. This is done to provide the user with a seamless experience, so they are not required to authenticate again for every page that they visit. If the website approves of the session cookie and considers the user session still valid, an attacker may use CSRF to send requests as if the victim was sending them. The website is unable to distinguish between requests being sent by the attacker and those sent by the victim since requests are always being sent from the victim’s browser with their own cookie. A CSRF attack simply takes advantage of the fact that the browser sends the cookie to the website automatically with each request.

Cross-site Request Forgery will only be effective if a victim is authenticated. This means that the victim must be logged in for the attack to succeed. Since CSRF attacks are used to bypass the authentication process, there may be some elements that are not affected by these attacks even though they are not protected against them, such as publicly accessible content. For example, a public contact form on a website is safe from CSRF. Such HTML forms do not require the victim to have any privileges for form submission. CSRF only applies to situations where a victim is able to perform actions that are not accessible to everyone.

CSRF example

A typical GET request for a $100 bank transfer might look like:

GET$100 HTTP/1.1

A hacker can modify this script so it results in a $100 transfer to their own account. Now the malicious request might look like:

GET$100 HTTP/1.1

A bad actor can embed the request into an innocent looking hyperlink:

<a href="$100">Read more!</a>

How can cross-site request forgery (CSRF) be prevented?

  • Same-Site Cookies

The Same-Site Cookie attribute is a newly developed attribute that can be set on cookies to instruct the browser to disable third-party usage for specific cookies. This attribute is set by the server while at the same time setting the cookie itself, and requests the browser to only send the cookie in a first-party context. Because of this, the request has to originate from the same location. Therefore, requests made by third-party sites can not include the same-site Cookie. This effectively eliminates CSRF without requiring the use of synchronizer tokens. The only downside is that Same-Site Cookies are only available in some modern browsers.

  • Anti-CSRF Tokens

The recommended and most widely adopted prevention method for Cross-site Request Forgery is an anti-CSRF token, otherwise known as a synchronizer token. When a user submits information or interacts with the site, or does anything else that generates a cookie, the anti-CSRF token should also be included with the cookie request. This request then gets run through a verification process, wherein the authenticity or even existence of this token is verified before processing the request. If the token is missing or incorrect, the request can be rejected.

To insure quality of protection with Anti-CSRF tokens, it is essential that the library of known tokens is regularly updated to match existing threats. Many of these libraries are open source and easily accessed. In a perfect world, both methods would be combined to help defend against a CSRF attack.

  • Challenge Response

As an additional layer of protection, you can require a challenge response from a user when a form is submitted. Some examples of challenge responses include:

  1. Re-Authentication of Password or Personal Information
  2. CAPTCHA validation
  3. Issue a one-time token

While challenge-response can be an effective deterrent against CSRF when designed and implemented accordingly, it does have an impact on user experience. For applications in need of high security, both tokens and challenge-response should be used to ensure security.

Related Post

Leave a Reply

Your email address will not be published. Required fields are marked *