The Day Something Felt "Off"

During a recent security assessment of an organization's internal application, everything initially looked… normal.

Login page? ✔️ Session token? ✔️ Authentication flow? ✔️

But in cybersecurity, the most dangerous vulnerabilities often hide behind "normal." And this one started with something very small… a token.

🎯 The First Clue: A Token That Never Changes

Like most web applications, this system generated a session token as soon as I opened it in the browser. Nothing unusual. But after logging in, I noticed something strange:

The session token didn't change.

That immediately raised a red flag.

Because, in a secure system, session tokens should always be regenerated after authentication to prevent attacks like session fixation. So I decided to test something.

🧪 Experiment: Can Two Users Share One Session?

Here's what I did:

  1. Opened the application → captured the session token
  2. Logged in as a normal user
  3. Copied that same token into another browser, and then…

💥 Boom. I was logged in as the same user in the second browser — without credentials.

🚨 What Just Happened?

This is a classic Session Fixation vulnerability. In simple terms:

  • The application trusts a session token before login
  • It continues trusting the same token after login
  • Anyone with that token can reuse it to hijack the session

🔥 Why This Is Critical

Imagine this in a real-world scenario:

  • An attacker tricks a user into using a predefined session (via phishing, proxy, etc.)
  • The user logs in
  • The attacker reuses that same session token

👉 Result: Instant unauthorized access to the victim's account

No password. No alert. No friction.

🛠️ How to Fix It

This issue exists because of improper session handling. Here's how to fix it:

  • ✅ Regenerate session tokens immediately after login
  • ✅ Invalidate any previously issued tokens
  • ✅ Use secure cookie attributes (HttpOnly, Secure, SameSite)
  • ✅ Implement session expiration and inactivity timeouts
  • ✅ Optionally bind sessions to IP/User-Agent (carefully)

😈 But That Wasn't the Worst Part…

While testing further, I found something even more dangerous.

A vulnerability that didn't just let me access accounts… It let me own them.

🔑 The Second Discovery: Changing Anyone's Password

Inside the application, there was a standard feature:

"Change Password"

Seems harmless, right? So I intercepted the request and noticed something interesting:

  • The request included an employee ID
  • The system used that ID to decide whose password to change

So I tried something simple…

👉 I replaced my employee ID with another user's ID.

Sent the request. And…

💥 Their password was changed instantly. Even no need to match the victim's current password.

🚨 What Just Happened (Again)?

This is a textbook IDOR (Insecure Direct Object Reference) vulnerability.

The application was trusting user input without verifying authorization.

🔥 Why This Is Even Worse

This means:

  • Any logged-in user can change any other user's password
  • No need for the current password
  • No ownership validation
  • No restrictions

👉 Result: Full Account Takeover (ATO)

And yes… that includes admin accounts.

🧪 Realistic Attack Scenario

An attacker could:

  1. Log in with a low-privilege account
  2. Change the password of a high-value target (e.g., manager/admin)
  3. Log in as that user
  4. Move laterally across the system

👉 Complete compromise of the internal application.

🛠️ How to Fix This

This is a classic authorization failure. Here's how to secure it:

  • ✅ Enforce strict server-side authorization checks
  • ✅ Ensure users can only modify their own accounts
  • ✅ Never trust user-controlled identifiers (like employee ID)
  • ✅ Validate identity using session context, not request parameters
  • ✅ Require current password for password changes
  • ✅ Add MFA for sensitive operations

💣 The Dangerous Combination

Individually, both vulnerabilities are critical. But together?

They are devastating.

  • Session Fixation → Gain access to a user session
  • IDOR → Change their password → Lock them out permanently

👉 Complete account takeover chain

🧩 Final Thoughts

This assessment reinforced a simple but powerful truth:

Security is not just about authentication — it's about what happens after.

  • A valid session means nothing if it can be hijacked
  • A login system is useless without proper authorization

Even internal applications — especially in banking environments — must follow strict security practices.

Because attackers don't care whether a system is "internal" or "external."

🏁 Key Takeaways

  • Regenerate session tokens after login
  • Never trust user input for sensitive actions
  • Always enforce authorization checks
  • Protect critical functions with re-authentication

Md Mesbaul Islam, Cyber Security Researcher & Ethical Hacker