CSRF (Cross-Site Request Forgery) attacks aim to perform unwanted actions in the background by abusing the user's identity. So, how do they work? Typically, when the victim has an active session on a web application, the attacker sends a request to the server via a malicious link/form they've prepared. The application verifies the request as coming from a legitimate user and executes the action, such as changing an email address—a sensitive function. So, how can we prevent this? CSRF tokens, SameSite cookie settings, and CORS policies are the most common methods.
What is CSRF and how does it work?
👁️ 10 views💬 2 replies❤️ 0 likes
2 Replies
Witnessed a CSRF attack a few years back while auditing a legacy payment gateway. At the time, I was testing a demo environment on an e-commerce site where users could update their membership details from the "My Account" tab. The attacker hid a URL in an image tag that sent a direct `POST /update-email` request—pretending it was me sending it. Since there was no CSRF token protection in the browser, the server accepted the request as legitimate and attempted to change my email.
The most dangerous part of the process was that this request happened in the background, just like a normal form submission, without the user noticing. Since the user had to already be logged in, the vulnerability was highly exposed to attack. After examining the field, we closed this gap by adding `SameSite` cookie policies and token verification to the application. Remember, the simplest and most effective protection against CSRF is token-based verification—make sure to use it!
CSRF, in simple terms, requires something that convinces the user to click—like fake links such as "Clear Recycle Bin" or "Earn Free Bitcoin." But the real danger is that when the user clicks, the browser automatically attaches their credentials (cookies, session tokens). The attacker's goal isn't to make it look like "I sent this request," but rather to create the illusion that "the user sent it."
What’s important is that CSRF attacks work *between requests*—meaning through a third-party site. For example, while the victim is using their banking site, a hidden image link or a secret form set up by the attacker triggers in the background. When the server checks "Who sent this request?" it only sees the cookie, not the content. That’s why security flaws often surface in state-changing actions (like transferring money or changing passwords).
Current protection methods include CSRF tokens (hidden, unpredictable tokens), SameSite cookie policies, and the double-submit cookie pattern. Remember, CSRF doesn’t target the user’s computer—it targets the web application the user trusts.