CSRF is one of the most known web application vulnerabilities, but, it could be pretty hard to understand it deeply.
So I’m trying to make this introduction to CSRF as beginner-friendly as possible.
I assume that the reader has a minimum of basic IT knowledge.
Curiously, people usually understand XSS or SQL injection better than CSRF, even if they are more tricky in my opinion.
I guess that they lack the right basics of how the HTTP protocol works.
That’s why before starting with the gist of the article, I would like to briefly introduce the parts of HTTP that are essential to understanding the CSRF attack.
How does the HTTP state work?
HTTP is a stateless protocol by design but unfortunately, it is sufficient with web applications so there was a need for a solution.
We need to keep some data when moving from one page to another (try to imagine a step-by-step online chart or maybe a web application which requires keeping the login state).
To solve this problem a feature has been introduced by which the server can store the information about the user’s session in a cookie. Now the concept should be a bit clearer, but I want to spend just a few words briefly expanding on some concepts like cookies and sessions.
What is a cookie?
In computer science:
“A cookie is a small piece of data that a website sends and that the user’s computer stores through its web browser while the user is browsing.“
Their main goal is to make the server easily identify the client.
Every cookie has a label with a unique id which will be the key for the client search later.
What is a session?
At this point, we have all the required elements to understand what the sessions are.
So if we want to define a session in one sentence:
“session is a temporary and interactive information interchange between two communication systems”*.*
The web application normally creates the related session at the first request (when the user accesses the page).
Depending on the developer’s choices, the server can store its session in different places:
Database: A simple implementation can be a column containing the session identifier, a foreign key to the session data and an expiring time.
Cookie: Another possible choice is to save all the session data inside an encrypted cookie.
File: The server can use temporary files to store all the sessions.
Cache-Based Storage: a very used and fast option is the usage of systems like Memcached and Redis.
Arrays: That’s not a very common way but the session can also be stored inside an array.
After that, the server sends a cookie containing a unique session identifier (or the encrypted session depending on the cookie storage configuration) to the user’s browser.
At the next request, the browser can send back this identifier to the server, allowing the server to identify the user and retrieve the user’s stored data.
The session exists until the user leaves the site or closes the browser (that could not be valid in case of persistent sessions).
I would like to conclude this brief digression on the sessions by mentioning what persistent sessions are.
Persistent sessions are the sessions that survive the closing of the browser, try to imagine the “remember me” function we can find on many websites.
There are some storage methods, like the one with arrays, that can be incompatible with this kind of session.
What is a CSRF attack?
Now we understood what are the sessions, it’s time to start with the real introduction to the CSRF attack.
A CSRF attack is a type of attack that occurs when:
web page
email
blog
instant message
program
causes an authenticated user’s web browser to perform an unwanted action on a trusted website.
The effect of the attack may vary, from logging out the user from the site to making unwanted purchases or changes to the user’s data.
In essence, this type of attack takes advantage of the sessions/session ids already stored in the user’s cookies.
So, the attacker can trick a victim into making an HTTP request (by crafting a malicious URL in case of a GET request or a web page). The receiver of that request is a web application that will read the session and think that it’s a legit operation.
How to prevent a CSRF Attack?
That wouldn’t be a good introduction without explaining how to successfully prevent the CSRF attack.
There are many ways to mitigate a CSRF attack, but, as I said it’s just an introduction, so I want to list just the common ones.
CSRF Token: that’s a one-time token randomly generated
CAPTCHA: forcing the user to insert a CAPTCHA can stop a malicious request
Re-Authentication: it consists in asking the user to authenticate again before proceeding. It assures the consensus of the potential victim ( try to imagine when you want to change your password and the system asks you for the old one before continuing).
SameSite Cookie Attribute: it’s a cookie attribute that will consent you to specify a policy for cookies. By setting it to LAX, it should prevent cross-site requests. You can find more info in RFC6265bis.
WAF: Web application firewalls are another possible mitigation for CSRF attacks
If you want to learn more you can find a good resource at this link.
Introduction to CSRF token and what is it?
A CSRF token is a unique, secret, random string of characters that the server generates and attaches to each form that is served to the user.
You can generally find it in a hidden form field and has to be sent back to the server user’s submission, after that the server verifies if it matches.
If the form contains an invalid, the receiver rejects the submission.
This prevents attackers from being able to submit the form on behalf of the user because they should guess the user’s secret token.
In other words, this measure relies on the generation of the one-time token
So if an attacker wants to craft his request, has to pack the CSRF token inside that.
And since the application generates a token with a random function for each request, the attacker has a probability to guess it close to zero.
You should also consider that even if the length of the token depends a lot on the underlying application, it’s always big enough.
Many frameworks like Django and RubyOnRails use a token 32 characters long.
Example of CSRF attack
A good introduction to the CSRF attack cannot go without a detailed example that makes the concept even clearer!
To clarify the concept I want briefly discuss the steps of a possible CSRF attack, so let’s imagine the following scenario:
A malicious website contains a link that submits a form to a trusted website.
The user visits the malicious website and the browser sends the form submission to the trusted website.
The trusted website processes the request and the user’s account is updated without their knowledge or consent.
At this point, you can imagine that the request can be:
Password Change
Money transaction
Sending personal information
And much more, I hope this example may have given you a clearer picture of the dangerousness of the CSRF attack.
What are the consequences of a CSRF attack?
In the previous section, we mentioned possible uses of a CSRF attack, however, I want to emphasize the dangerousness of such an attack.
In particular, the consequences of a CSRF attack depend on the type of action that the attacker performs and they depend mainly on these factors:
User’s security awareness.
The ability of the hacker.
The severity of the vulnerability.
For example, if the attacker tricks the user into submitting a form that changes the user’s password, the consequences could be very serious. The attacker could then log in to the user’s account and perform any action that the user can perform. So in this case, try to imagine what he can do if that user has administrator privileges.
In other cases, the attacker could trick the victim into performing some banking transaction.
And much much more…
CSRF VS XSS VS PHISHING
XSS is a type of attack that is used to inject malicious code into a web page, there are many types and you can find a detailed guide starting here.
CSRF is a type of attack that is used to act on behalf of the user without their knowledge or consent.
Phishing is a type of online scam where criminals pose as a trustworthy entity to trick victims into giving up personal information, such as login credentials or credit card numbers. It can happen via email, text messages, or even fake websites that look identical to the real thing.
However, a hacker can combine those attacks, as we have seen to perform a CSRF attack.
The attacker’s final goal is to deliver a crafted URL or a web page.
He can do it in some ways, for example by sending an email containing the malicious URL or page link.
You can imagine also a chain of attacks, like in this example:
The attacker finds an XSS vulnerability in a trusted website and injects a redirection script that submits a malicious form to the CSRF-vulnerable website.
After that, he sends an email to the victim asking him to click on the link.
The victim sees a trusted website and clicks on that.
It will allow us to bypass the Same Origin Policy mechanism.
Conclusion
CSRF attacks can be very harmful and have serious consequences. To prevent CSRF attacks, web applications should use unique tokens for each user and attach the token to each form that is served to the user.
The old browsers could not support SameSite Cookie Attribute, so when possible, use always updated software.
Today every framework has support for CSRF protection so if you are a developer make sure it is enabled.
In conclusion, even if it’s no more in OWASP TOP 10 from 2017, it can still represent a serious threat.
I hope you enjoyed this introduction to CSRF post, and if you like my work you can support me by continuing to follow my blog and my socials.
See you soon with a new article!