How to prevent the infamous CSRF attack
When we talk about cybersecurity and hackers, a lot of us imagine an hacker in a dark cellar, typing on the keyboard at the speed of light.
However, a lot of hacking is more similar to fishing: you need patience, you need silence, you need a good prey.
The Cross-Site Request Forgery attack was listed into the OWASP TOP 10 2013, but still today, where cybersecurity knowledge is more diffused among developers’ population, can be a serious, lethal threat.
Whenever I listen to developers, their main concern is to release on time. I get their point, but saving on security is never a good idea.
So, let’s start drilling-down CSRF attacks. I’ll tell you why they are dangerous and what you should do to avoid them.
The “Cross-Site Request Forgery” (CSRF) Attack
We are the owners of a famous web application. Our web server sends a bunch of cookies back to the client, session cookies as well as tracking ones.
Checking the documentation and browsing the Internet for some ideas to furtherly expand our business, we see that other people web applications cookies are full of flags and there are strange magical words like “SameSite: Lax”, “SameSite: Strict”. Every form of their web applications is accompanied with an alphanumerical string named “antiCSRFToken”. Still, we don’t understand why, but our website is successful, so who cares?
We keep browsing, clicking here and there, then we come back to our website: we cannot access our profile, our password is changed, it seems that someone stolen our account.
What’s happened?
There are several problems in our Change Password form. I’m going to list some of them:
- Our form didn’t ask for the previous password
- Our form isn’t accompanied by an anti-CSRF token
- Our session cookies don’t have the SameSite flag properly set, so our browser sends them with our request, even if it originates from another website
So, we clicked somewhere on an evil website and a POST request to our Change Password was sent.
The Evil CSRF
What’s the lesson learned from the above paragraph? Nothing was saying our server that the user’s action was intentional. He was just browsing and clicking on another website and something happened.
If our website forms have no countermeasures, CSRF attack could happen everywhere. They can change our username, our profile, send message on our behalf, and so on. The only thing they cannot do is to read the server reply, since the Same Origin Policy is in effect.
But it is still very destructive: just think about a banking application where anti-CSRF measures are missing. An attacker could transfer money on our behalf while we are browsing another website.
Testing for CSRF
The early signs of a chance to perform a CSRF attack are:
- Lack of an unique, random, unpredictable anti-CSRF token accompanying forms
- Lack of Samesite flag applied to cookies
- No custom headers needed to perform a POST request
A powerful software like Burp Suite Pro can help us finding CSRFs. By right clicking on a request, we can open Engagement Tools and generate a PoC to exploit CSRF. Burp will generate a simple HTML page where one button is present, but it will suffice to try a CSRF attack.
By pressing F12 on a browser like Firefox and then going to Storage > Cookies, you will find your cookies settings. As you can see from the image below, the SameSite status is varying among my cookies. I will explain the meaning of the other settings in another article, so be sure to follow me to not miss it :)
CSRF Prevention
Nowadays, we have a lot of weapons to prevent CSRF.
- The first one, of course, is a random, unpredictable, unique anti-CSRF token accompanying the forms that our server sends to the user’s browser. In my career as a penetration tester, I found anti-CSRF token that weren’t unpredictable. Sometimes I overwrote the token with another sequence just to find that the token was not properly checked. Notice that a third-party website couldn’t read our website when the latter is operating under standard conditions. We have to pay attention to the CSRF token, since bad validation equals missing validation. If an evil actor can bypass a check, he’s going to attack the users of our platform. It’s just a matter of time and probabilities. And why should your user choose your platform, when you’re not caring about him?
- Samesite flag. If you’re only relying on user’s session cookie to decide whether actions are intentional or not, you’re wrong. However, you can choose if the browser can attach the cookies issued from your website to requests originating from another place. There are different options for this flag, which should be specified for each cookie: Lax, Strict and None. Lax means that the browser can attach the cookie only to GET requests originating from another website. GET requests will not provoke a state change (e.g. you don’t use a GET request but a POST to alter the user profile, usually). If a POST request originates from another website, then the browser will refuse to attach the session cookie and your server will deny the access, since no session cookie is specified. Strict means that it doesn’t matter the request, the browser will NEVER attach the cookie when the request is originating from a place different from your website. Then we have None, which simply means “no policy applied”. It all depends on your browser, some of them default the value to Lax. Be aware: don’t use GET requests to alter a state (e.g. to change the username, to edit the email), since the Lax policy allows the cookies to be attached. In this case, your application will be susceptible of attacks, anyway!
- Custom Headers. Make your server require custom headers to perform actions. Even if an attacker manages to capture the user’s anti-CSRF token, the browser will refuse to send custom headers cross-domain. The presence of a custom header requires the request to be preflighted: if your server will not reply with an “
Access-Control-Allow-Headers: MyCustomHeader", the request will be unsuccesful. - Check the Origin. Make a whitelist of allowed origins. If the Origin matches the target origin, then this check is ok.
Conclusions
I hope that I’ve not confused your ideas about CSRF too much. CSRF attacks are still a dangerous threat and I think only by disseminating all the information we have can we build a better web. Never forget that prevention is the key, and follow me for more! :)
