Nope. I was working on XSS even before I started writing this page. It's been almost 2 weeks now, and I'm still learning it. There are still many things left for me to understand in XSS.

But here's the thing — if I stick to only XSS for too long, I might miss out on learning other vulnerabilities. In cybersecurity, new things keep adding up over time. So it's not practical to completely master one thing and then move to the next.

Instead, the better approach is to reach a certain level in one vulnerability, and then move forward while continuing to practice it.

So how do I know I've reached that level?

Simple.

First, I learn the theory. Questions naturally pop up in my mind. Then I research those questions, find answers, and write notes in my own language so I actually understand them.

After that, I go through the same concept on different platforms, read blogs, watch YouTube videos — basically see it from multiple perspectives until it becomes clear.

Once I feel confident about the concept, I move to labs and practice at least 10–15 labs. At that point, I have a solid basic understanding and can recognize how that vulnerability works in real scenarios.

Then I move on to the next vulnerability — but I keep practicing the previous one as well.

That's the approach I'm following right now.

Anyway, last night I worked on CSRF.

As per my understanding, CSRF (Cross-Site Request Forgery) is an attack that forces an authenticated user to perform an action on a web application without their consent. It works when the application cannot properly differentiate between a legitimate request made by the user and a malicious request made on their behalf.

Now, the way I like to understand things is by building a clear visual in my head.

So I started with a basic lab. In this lab, the email change functionality was vulnerable to CSRF, and I was given login credentials to access the account.

My Approach

I logged in and tried changing the email while capturing the request using Burp Suite.

Then:

  • I analyzed the request in Burp Proxy
  • Checked cookies in the browser (Inspect → Application → Cookies)
  • Noticed there was also a "host" page provided in the lab

But honestly, at that point, I had no clear idea how I was supposed to use that host page.

None

After struggling for about 30 minutes, I checked the solution briefly to understand the direction, then came back and continued.

Step-by-step exploitation

None
  1. I captured the email change request (already done)
  2. Sent it to Repeater to test and modify it
  3. Removed unnecessary headers to simplify the request
  4. Confirmed the request still works properly

Now the main part:

I needed to create a CSRF PoC (Proof of Concept)

Normally, Burp Suite Professional has a built-in feature for this, but since I don't have it, I used an online tool.

I used: https://csrfshark.github.io/

None
  • Pasted my modified request into the tool
  • It generated a CSRF PoC for me
  • Copied that PoC

Exploiting the vulnerability

Then:

None
  • I pasted the PoC into the exploit server (host page) provided in the lab
  • Saved it
  • Clicked "View Exploit"

A simple HTML page loaded with a submit button.

I clicked it → went back to the account page → and the email was changed

Final Step (Automation)

To make the attack more realistic, I added this JavaScript:

<script>document.forms[0].submit();</script>

Now:

  • The form auto-submits as soon as the page loads
  • The user doesn't need to click anything

This makes the attack seamless and more dangerous.

Final Result

None

Delivered the exploit → Lab solved successfully

Resources I used

For CSRF PoC generation:

Final Thoughts

This lab really helped me understand how simple requests can be abused if proper protections are not in place.

If you're learning, don't just copy the solution — try to struggle a bit, understand the flow, and then come back stronger.

Thanks for reading. If this helped you even a little, I really appreciate it

See you in the next story. Till then, keep solving those errors.