June 2, 2026
How Chaining Two IDORs Led to a Mass Data Harvesting of a Government University π
Hello, hackers and bug hunters! Today, Iβm thrilled to share a story about patience ,And how a seemingly βdead-endβ target turned into aβ¦
0xmones
3 min read
Hello, hackers and bug hunters! Today, I'm thrilled to share a story about patience ,And how a seemingly "dead-end" target turned into a goldmine of data through a beautifully chained exploit.
Let's dive in! π±βπ€
π― The Target & The Mirage (Recon Phase)
It all started with an Asian governmental university website. Looking at their bounty table, it was a bit⦠funny.
- Low: $10
- medium: $30
- High: $60
- Critical: $100
But hey, we are not just here for the money; we are here for the thrill of the hunt
For two consecutive days, it was pure frustration. Intensive Recon, but everything returned 403 Forbidden. The website looked mostly static, boring, and dead. I was literally about to close Kali Linux, shut down my laptop, and go to sleep.
But then, one specific endpoint caught my eye. The game was officially ON. π₯
πͺ Step 1: Entering the Matrix
The website wouldn't let me browse anything without an account. So, I headed to the registration page. The form was aggressively detailed β asking for National ID numbers, city, village, father's occupation, and highly sensitive data.
I registered with completely fake, randomized data, set up my Burp Suite, and started digging. It still felt like a static maze, but I ran some fuzzing on hidden directories and endpoints.
Then, PART 1 of the vulnerability was uncovered.
π§© PART 1: The Puzzle Without a Key (Vulnerability )
- Vulnerability Type: Insecure Direct Object Reference (IDOR) / BOLA
- Severity: High
While analyzing the background requests, I noticed this interesting endpoint: [https://example.com/getQPic?stID=[My fake National_ID]
This endpoint fetched the student's profile picture using their National ID as the parameter (stID).
Naturally, I tried changing the ID to random numbers. Nothing. Why? Because the National IDs in that country follow a strict, complex pattern. How on earth could I guess the real National ID of a random student?
The vulnerability was there, but it was practically useless without a valid ID. It was a dead end. I left it and kept hunting.
π₯ PART 2: Never Trust User Input! (Vulnerability 2)
- Vulnerability Type: Insecure Direct Object Reference (IDOR) / BOLA
- Severity: Critical π₯
While exploring the portal, I decided to download a document related to my fake profile. The download link looked like this: [https://example.com/readAttach/stApplic?attachID=145785]
My inner hacker immediately whispered: "What if we change that attachID number?" π
I changed the ID by just one digitβ¦ BOOM! π₯ A file downloaded instantly. It was a picture of a female student.
I incremented the ID again β phone numbers, private registration images, and even .rar backup archives of student files!
Then, I hit the jackpot. I stumbled upon a 30MB Excel spreadsheet. I downloaded it, opened it, and couldn't believe my eyes.
The sheet contained tens of thousands of students' full records:
- Full Names & Parents' Names
- Home Addresses
- Financial Statements & Tuition Fees
- And most importantly: Their Valid National IDs! π
π The Chain: Mass Data Harvesting Complete!
Now I had the missing piece of the puzzle. I took one of the real National IDs from the leaked Excel sheet, went back to Vulnerability 1 (/getQPic?stID=), pasted it, and... BOOM! The second time! The student's photo appeared perfectly.
By chaining these two IDORs together, an attacker could harvest the complete identity of every single student in the university: Their financial history, personal phone numbers, home addresses, and official photos.
A total data catastrophe, handed over by a website that looked "too static" to have vulnerabilities.
Superman saves the day again! π¦ΈββοΈ
π‘ Takeaway for Developers
Dear developers, if there is one golden rule you should write on your office walls, it's this:
"NEVER TRUST USER INPUT."_ β_
Always implement robust, server-side object-level authorization checks. Just because a user is logged in doesn't mean they should have access to Object_ID + 1.
Thanks for reading, stay curious, and happy hunting! π
ΩΨ§ΩΨ³ΩΨ§Ω ΨΉΩΩΩΩ ΩΨ±ΨΩ Ψ© Ψ§ΩΩΩ ΩΨ¨Ψ±ΩΨ§ΨͺΩ βοΈ