The Hidden IDOR That Took Down Redirected.com 🤯

Ah, IDOR vulnerabilities — what are they good for? Unauthorized access to someone else’s to-do list? Meh, boring. But what if I told you that an IDOR could lead to complete domination of an entire web app? 🚀 Buckle up, because today, I’m going to take you on a wild ride through an IDOR vulnerability that snowballed into full-blown ownership of Redirected.com (totally a real app, I swear! 😜). If you’re thinking “IDORs are easy!” — well, think again.

Phase 1: The Gateway to Chaos

So, there I was, casually testing Redirected.com, a massive SaaS platform handling user accounts, roles, and admin features. Everything seemed tight… until I stumbled upon an innocent-looking endpoint:

/account/modify/<uuid>/transfer

This endpoint was meant to allow admins to transfer accounts between users. Except… something smelled fishy 🐟 (and not the good sushi kind). It turns out, the API didn’t strictly enforce access control checks. Like, at all. 🤦‍♂️

The First Sign of Trouble: Metadata Galore

Time to poke around! I crafted a request to transfer an admin’s account to my lowly user account. But Redirected.com’s server responded with an error. At first, I thought, “Pfft, this app is smarter than I thought.”

But then… 💡 I realized the error response was leaking sensitive metadata — specifically, internal role IDs and account UUIDs of admin users! These juicy tidbits were about to become my golden ticket 🎟️.

Phase 2: The Role Swap That Shouldn’t Be Possible

Using the leaked metadata, I found an orphaned endpoint /role/modify/<uuid>. This endpoint should have required strict permissions for role modification. But surprise! The developers never actually put those checks in place. 😬

Now, I didn’t just want access to another user’s account — I wanted admin privileges! 💼 So, I tweaked the request to modify the admin’s role and… 🎉 BAM! My user account was now sporting shiny new admin rights. I was living the dream! (Well, at least the hacker’s dream.)

Phase 3: Session Fixation FTW

At this point, I was feeling pretty powerful. But, like any responsible hacker, I knew admin privileges weren’t enough. What if they revoked my access? 😱 Not on my watch!

The app had a critical flaw: session fixation. This allowed me to lock my session in place before authentication even happened. It was like getting the keys to the admin’s mansion 🏰 and changing all the locks. Even if they figured out something was wrong, they couldn’t kick me out. Cue evil laughter 🦹‍♂️.

Phase 4: SSO — The Achilles’ Heel

But wait, there’s more! Redirected.com used Single Sign-On (SSO), and I was curious: Could I break in even further? 🤔 (Of course I could!)

Here’s where it gets juicy 🍉: The SSO trusted user-provided tokens without actually verifying them with the Identity Provider (IDP). Whoops. Now, using my newly acquired admin access, I forged an SSO token that let me impersonate the super-admin — basically the god of all accounts. 🎩

In doing so, I gained access to the entire platform, including settings, user data, and admin privileges galore. If I wanted, I could’ve turned off the whole site… but that’s just mean. 😇

Conclusion: How an Innocent IDOR Escalated Into Full-On App Takeover 🚨

Most people think of IDORs as harmless little flaws that maybe let you peek at someone else’s data. But this saga shows that an IDOR — when combined with metadata leaks, orphaned endpoints, session fixation, and SSO misconfigurations — can lead to total system compromise. 🙌

So, what have we learned?

• Always validate permissions server-side. 🔒
• Never assume UUIDs make you invulnerable. 🧩
• Fix your session fixation issues, seriously. 🛠️
• Test your SSO like your life depends on it. ⚠️

Because if you don’t, someone like me might come along, chain these flaws together, and own your entire platform. 💥

Happy Hacking, Cheers 🍻🍻