Welcome back. This one is about chaining two IDORs into account takeover, no victim interaction required. It came out of a helpdesk program I spent a few months on.
The target
The app had three roles: admin, manager, and user. Admins manage everything, managers have most access except org settings, and users only handle assigned tasks. Admins can create departments and assign managers to them, and they can add or edit users, change emails, change passwords, and lock accounts. I found one IDOR in the department assignment flow and another in the user edit flow. Each looked minor alone. Together they gave full account takeover.
IDOR #1: assigning a department
The assign-department action was simple: create a department, add a manager, click save. The request carried the manager's id. By swapping that id for another manager's, the app happily added that manager to my department, even a manager who belonged to a completely different organization. That detail matters: it means the flaw can reach accounts outside your own org.
On its own this looked low impact, mostly letting you spam managers across departments. I documented it and moved on.
IDOR #2: editing a user
Next I looked at the user edit feature, where admins change a user or manager's email and password. I captured a password-change request in Burp and saw it included the user id. I replaced that id with the manager id from my second test account and sent it. The server returned 200 and the password changed. I logged straight into that manager account.
The catch
It looked like a clean P1, until I started recording the proof of concept and it stopped working, returning 403 instead of 200. I couldn't see why it had worked moments earlier.
The answer was the link between the two bugs. The password change only worked for managers who were currently in my department. In my first successful test I had already added that manager using the first IDOR. During the PoC I was targeting a manager who wasn't in my department, hence the 403. That was the chain revealing itself.
The chain
Put together, the takeover is four steps:
- Use the department-assign IDOR to add the target manager into your department.
- Modify the password-change request to target that manager's id.
- The server returns
200and the password is updated. - Log into the manager account with the new password.
Both IDORs were trivial alone. Chained, they give full account takeover with no victim interaction. And because the first IDOR pulls in managers from other organizations, the chain reaches accounts outside your own org, I verified it worked against admin accounts in other organizations too.
Key takeaway
It took some persistence to spot the link between the two flows. The lesson: don't ignore small findings, try to connect them. If a flow looks harmless on its own, ask how it might combine with other actions. That mindset is what turns minor issues into high-impact ones.
Questions or feedback? Reach me on LinkedIn, Sheraz Khalid. Thanks for reading, see you in the next writeup.