What is CSRF?

So, what is it?

Think of it like this: the internet is a giant, bustling city. Websites are buildings, you are a resident with keys (your login session), and actions you take online are like transactions in this city. Now, imagine a sneaky pickpocket – that’s our CSRF attacker. They’re not trying to steal your keys directly. Oh no, they’re much more cunning than that. They're going to trick someone else – in this case, a website – into thinking they are you and doing something on your behalf, without you actually authorizing it. Sneaky, right?

Let’s break it down in plain English. CSRF is a type of web security vulnerability that lets an attacker cause users to unknowingly perform actions on a website they're already logged into. The key here is unknowingly. You're not handing over your password. You're not clicking on something obviously dodgy. It’s all happening…behind the scenes.

To really make this stick, let’s pull out a classic analogy, the one you hinted at: your bank account. Because nothing makes security vulnerabilities more relatable than the fear of someone messing with your hard-earned cash.

Imagine you're logged into your online banking. You've just transferred some funds, checked your balance, you know, the usual responsible adult stuff. Your bank’s website, all secure and official, is happily keeping you logged in, using something called a session cookie (we won’t get too techy, but think of it as a temporary ID card that says "Hey, this person is already verified!").

Now, you’re done with banking for the day, but maybe you leave the tab open in the background because, hey, who has time to close every single tab? (We all do it, don’t lie). You innocently browse around the internet, maybe check out some cat videos (as one does), or perhaps you stumble upon a forum full of…well, let’s just say “enthusiastic” opinions.

Unbeknownst to you, lurking somewhere on a dodgy corner of the internet, or even sneakily embedded in a seemingly harmless website or email, is our CSRF attacker. They've crafted something…nasty. It’s a special kind of web link, or maybe a hidden form, that they’ve designed to target your bank. It’s specifically crafted to look like a legitimate request to your bank, something like:

http://yourbank.com/transfer.do?toAccountNumber=123456789&amount=1000

See that? "transfer.do", "toAccountNumber", "amount". Looks kinda like a real bank transaction URL, right? The attacker has replaced the account number with their account and set the amount to something juicy, let's say $1000 (or whatever currency floats your boat).

Now, here’s the sinister bit. Because you're still logged into your bank, remember that session cookie? Your browser, bless its helpful but sometimes overly trusting heart, will automatically send that cookie along with any request to yourbank.com, even if you didn’t intentionally trigger that request.

So, let's say you innocently click on a link on that dodgy forum, or maybe you just visit a website where this malicious code is quietly running in the background. This click, or even just loading the page, triggers your browser to send that crafted URL – http://yourbank.com/transfer.do?toAccountNumber=123456789&amount=1000 – to your bank.

Your bank's server receives this request. It sees the session cookie you are logged in with. It thinks, "Aha! This is a legitimate request from a logged-in user!" It doesn’t know, or doesn't care, that you didn't actually click the "Transfer Funds" button on their website, or fill out any forms, or consciously intend to make this transfer. It just sees a valid request coming from a valid session and…BOOM. Transfer initiated. One thousand hypothetical dollars are whisked away to the attacker's account, all without you ever knowing you triggered it.

Imagine the horror when you next check your bank balance and realize you’re a thousand bucks lighter! And you didn’t buy anything cool, either. Just…vanished. That’s CSRF in action, in its most financially terrifying form.

Why does this work? What’s the loophole?

The problem lies in how websites traditionally authenticated user actions. They relied heavily on cookies to verify that a request was coming from a logged-in user. And, as we’ve seen, browsers are very helpful (sometimes too helpful) in automatically attaching these cookies to requests. The bank in our example is essentially saying, “If you show me the right ID (the session cookie), I trust you.” But the attacker isn’t stealing your ID. They are just cleverly getting your browser to present your ID on a forged request. It’s like someone copying your handwriting and forging a check – the bank (website) recognizes the signature (cookie) and processes the transaction, even if it’s fraudulent.

Okay, so banks probably wouldn't be that easily fooled in real life, right?

Well, hopefully, your actual bank has more robust security measures than just relying on cookies alone! And yes, modern websites and banks are much more aware of CSRF vulnerabilities and take steps to protect against them. But this vulnerability was, and to some extent still is, a real threat across the web. It's not just about money transfers. Think about other actions you take online:

• Changing your email address on a social media account. Imagine an attacker forcing you to change your email to theirs, effectively locking you out.
• Posting a tweet or status update. Imagine an attacker making you unknowingly tweet something embarrassing or damaging to your reputation.
• Purchasing items on an e-commerce site. Imagine unwanted items suddenly appearing on your doorstep, charged to your account.
• Changing your password. The ultimate lockout scenario.

The possibilities are as varied as the actions you can perform on websites. Anything that relies on session-based authentication and involves a state-changing action (like transferring money, changing settings, posting content) is potentially vulnerable to CSRF if not properly protected.

Conclusion

This article spoke about CSRF, a web security vulnerability, and is written by Ahmad Adel - who is a freelance writer and a backend developer.