Understanding Web Application Security Vulnerability - CSRF (Cross-Site Request Forgery)

Web applications are everywhere, but they can have security flaws. One such flaw is Cross-Site Request Forgery (CSRF), which exploits the trust your browser has in the websites you're logged into. Understanding CSRF is key to protecting your online interactions.

🔍 Introduction: What Are Web Application Security Vulnerabilities?

Web applications — from online banks to social media platforms — are everywhere. But just like physical buildings can have weak doors or broken locks, web apps can also have security flaws that attackers exploit. These flaws are called Web Application Security Vulnerabilities.

They’re essentially the "holes in the wall" that hackers use to sneak in or mess with things.

One such vulnerability is Cross-Site Request Forgery (CSRF) — a sneaky attack that takes advantage of the trust your browser has in the websites you’re logged into.

Let’s break it down in the simplest way possible. 👇

---

🧠 What is CSRF?

CSRF (Cross-Site Request Forgery) is when a malicious website tricks your browser into making an unintended request on a site where you’re already logged in — like your online bank or email.

✅ In short: You don’t click anything harmful — but your browser does something harmful on your behalf.

---

🍪 First, What is a Cookie?

A cookie is a small data file your browser saves when you log in somewhere — like a “Hey, remember me!” card.

Think of your browser as your assistant. If a site gave you a card (cookie), the assistant shows it automatically every time you visit the site.

• You log in to your bank → your browser stores a cookie.

• Later, every time you visit your bank, the browser sends that cookie, so the bank knows it's still you.

But here’s the problem…

---

💡 What Do Cookies Do in a Browser?

Cookies help the website remember things, such as:

• That you're logged in.

• Your shopping cart items.

• Your preferences, like language or theme.

---

🌐 How the Browser Uses Cookies

Example:

1. You log in to mybank.com.

2. The website responds:

   “Welcome! Here’s your session cookie – keep it safe.”

3. Your browser stores it like:
   cookie: sessionID=123abc

4. Next time you visit mybank.com, your browser automatically sends the cookie:

    GET /dashboard
    cookie: sessionID=123abc
   

5. The server says:

   “I recognize you! You're already logged in.”

---

🥜CSRF in a nutshell.

💣 Imagine This:

You're dining at your favorite restaurant (your bank) and you’ve already handed your VIP card (cookie) to the waiter.

Now someone from the next table (a malicious website) slips a fake order into the waiter’s tray 🧾.

Because your VIP card is on the tray, the waiter assumes the order is from you.

He serves it without asking questions.
You never placed the order — but it got served anyway.

🌍 In Real-World Scenario:

You’re logged in to mybank.com.
Then, you open a fake website called evilsite.com.

That evil site silently tells your browser:

“Hey browser, send this request to mybank.com/transfer?amount=1000&to=thief”

The browser does it because:

• You're already logged in to mybank.com.

• It automatically sends your session cookie with the request.

💥 Boom. The bank thinks you made the request and sends the money.

---

⚠️ Impact of CSRF

With CSRF, an attacker might:

• Transfer money from your bank account

• Change your password or email

• Post on your social media

• Delete your account

• Log you out

...all while you're just browsing cute cat videos.

---

📚 Where Does CSRF Fit in OWASP?

🔐 What is OWASP?

OWASP stands for the Open Worldwide Application Security Project — it's a non-profit organization that provides open-source resources and tools to help developers build secure applications.

Their most famous contribution is the OWASP Top 10, a regularly updated list of the 10 most critical security risks for web applications. It serves as a golden checklist for developers and security professionals alike.

Think of it as the Top 10 Mistakes Developers Must Avoid keeping their web apps safe.

---

🔟OWASP Top 10 – Web Security Risks (2021 Edition)

Here's a beginner-friendly table that breaks down the OWASP Top 10 with analogies:

---

📚 Where Does CSRF Fit in the OWASP Top 10?

CSRF is part of:

• A01 – Broken Access Control

• A07 – Identification and Authentication Failures

It used to be listed as a separate risk, but in newer OWASP lists (2021), it’s grouped under broader categories because it’s usually the result of poor session and authorization handling.

---

🛡️ How to Protect Against CSRF

1. CSRF Token – The Secret Handshake 🤝

   The website gives a unique, hidden code with each form.
   If a request doesn’t have this code, it’s rejected.

2. SameSite Cookies – Smart Cookie Control

   Set cookies to SameSite=Lax or Strict so the browser doesn’t send them during cross-site requests.

3. Double Submit Cookies

   Send the CSRF token in both: a cookie and a request field (form/header)
   Server checks if both matches.

4. Check Origin or Referrer Header

   Ensure the request really comes from your app’s domain.

5. Re-authentication for Sensitive Actions

   Ask for the user’s password before changing sensitive info (like email or password).

6. Never Use GET for Sensitive Actions

   GET requests are easy to embed in images/links. Use POST for anything that changes user data.

---

⭕Summary

---

🔚 Final Thoughts

CSRF is sneaky—it doesn’t steal your cookies, it uses them against you.
Modern security practices like CSRF tokens and SameSite cookies make websites much safer, but it's still crucial to understand how your browser handles identity.

When in doubt, log out. Or better, don’t open shady links while logged in to sensitive accounts.