Cross-site Request Forgery, also known as CSRF, Sea Surf, or XSRF, is a type of cyber attack in which the malicious attacker traps a user into performing certain actions on their behalf. The result of the attack is based on the level of permissions that the user has. Such attacks usually take place when a website happens to completely trust the user once the user proves who they are.
In the world of web application security, CSRF is often said to be the sleeping giant.
How are CSRF attacks done?
Most CSRF attacks exploit the end user’s inability to determine whether the content contains malicious code or not. Most attackers usually hide these elements using social engineering tactics like emails and chats.
There are two major ways in which a Cross-site Request Forgery attack is executed. In the first one, the user is tricked into clicking on a spammy link. This is normally done through malicious links. When the user clicks on these links, a targeted URL can bring about some change in the database (email data access, bank transfer, etc.) to a vulnerable web application that the end-user is currently accessing or has their session open on. This could be something where the user has a session open with the target website while they are logged in.
In the second part, a well-crafted, legitimate-looking request is sent from the victim’s browser to the website. Here, the request is shared with the values selected by the attacker that involves any cookies that the user has accepted in the website.
This way, the website understands that the user will perform certain actions on the website. Any request sent with these HTTP credentials or cookies will be considered legitimate, even though those requests are determined by the attacker.
Whenever a request is sent to the website, the victim’s browser verifies if it has any cookies that are linked to the origin of the given website and that is required to be sent along with the HTTP request. If so, these cookies are added amongst the requests sent to this website. The cookie value usually comprises the authentication data and such cookies shows the user’s session. Now, when the website apprtoves of the cookie session, it means that it considers the user session still valid. Therefore, whenever an attacker uses CSRF to send requests, it seems as if the victim was sending them. In this case, the website is unable to distinguish between requests being sent by the attacker and those sent by the victim since both the requests are deemed to be sent through the victim’s browser.
How to Prevent CSRF Attacks
There are myriad ways we can use to prevent the risk of CSRF attacks. Let’s find out how to do it on a Rails website.
CSRF Tokens
The most popular method most programmers use to prevent Cross-site Request Forgery is through a challenge token that is associated with a certain user that has a hidden value sent in every state-changing form in the web application. This token is known as an anti-CSRF token (often abbreviated as CSRF token) or a synchronizer token, works as follows:
- The web server generates a token and contains it
- The token is represented by a hidden code
- The form is submitted by the user
- The token is added in the POST request data
- The application compares both the token generated and stored by the application and the token sent in the request during the cookie session
- If both the tokens match, the request is valid
- If these tokens do not match, one can understand that its a malicious attack and the request is rejected
CSRF prevention using Ruby on Rails
Ruby on Rails typically comprises CSRF protection by default.
It statically sets the CSRF token in the session,
in the meta tags in the application’s <head /> tag.
Whenever we use form_for
or form_tag
or form_with tags for initializing a form,
Ruby on Rails sets the cookie session
and interchanges the hidden form field with the authenticity_token name.
Whenever a form gets submitted,
Rails compares both the session cookie and the form parameter and ensures that they are the same.
This way, it secures the protect_from_forgery line in our ApplicationController.
The same behaviour is then inherited by all the subclasses of the ApplicationController.
protect_from_forgery with: :exception
Other possible values are protect_from_forgery with: :null_session.
AJAX
The CSRF protection method is known as the synchronizer token pattern. It typically secures the form against CSRF attacks because an attacker would also need to identify the token, in order to make a victim send a valid request. The token should also be invalidated after the user logs out. Anti-CSRF tokens are often exposed via AJAX: sent as headers or request parameters with AJAX requests.
Rails typically sets a header known as the X-CSRF-Token
with the security token on every non-GET Ajax call,
by default.
If we use any other library to make AJAX calls,
it is important to add the security token
as a default header for AJAX calls in our library.
To acquire the token,
have a look at <meta name='csrf-token' content='THE-TOKEN'>
tag printed by <%= csrf_meta_tags %> in the application view.
