IDOR & Account Takeover

In this research, I discovered a critical vulnerability that allowed full account takeover due to improper access control mechanisms.

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: 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 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: 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