In the ever-evolving landscape of cybersecurity, hidden vulnerabilities lie beneath the surface, waiting to be discovered. Recently, I stumbled upon an Insecure Direct Object Reference (IDOR) vulnerability — an unsuspecting gateway that allowed me to delete the victims job alerts.

Talking about the target, it was a private VDP program from the Hacker one platform. The program had only “app.target.com” and “api.target.com” in scope. So it was quite easy for me to directly dive into the features and functionalities. The web app was all about the job portal kind where users search for their preferred jobs and apply to their favorite one. After playing abit with the applications functionalities, I found out that user can create an email alerts for the jobs that may interest them in the future. So I created an email alert for one of the jobs and intercept the request to understand how it was creating. Nothing here, as it was working fine with CSRF token, session validation was also properly implemented.

Since creating job alert functionality was working fine, I wanted to see how deleting the job alert request looks like. So, I turned on my burp intercept, deleted one of my job alerts and captured the request. The request was GET based, with long strings encoded. The one thing that was hard for me to understand was how the job alerts is being deleted with GET request without passing any parameters or alert id. The GET request was like:

GET /csr/index.cgi?SID=bW9kZT1kZWxldGUmcGFnZWNsYXNzPUFsZXJ0cyZhZ2VudF9jb2RlPTI2
NjAzOTMmcGFnZWFjdGlvbj1zdW1tYXJ5Jm93bmVyPTUwNzAwMDAmb3duZXJ0eXBlPWZhaXImcmVxc2
lnPTE3MDY1MTI1NTMtZjgwZTc4NmU2YzlhMGQ0NDgxNjkyMzI0YjNlZmVlYjFiMjViMDFmNg== HTTP/1.1
Host: target.com
Cookie: cookie-value
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Connection: close

The only thing remaining was to decode those encoded strings. Looking at their format most probably those were base64 encoded . So, went to my burp decoder, decoded the strings. The decoded value was: [mode=delete&pageclass=Alerts&agent_code=2660393&pageaction=summary&owner=5070000&ownertype=fair&reqsig=1706512553-f80e786e6c9a0d4481692324b3efeeb1b25b01f6]. Now I understand how the GET request was deleting the alert via mode=delete parameter. If you look at the agent_code, that's the alert-id of the job which was supposed to be deleted. Here, I created another job alert from my second test account, replaced the agent_code and sent the request.

But unfortunately, the request was unsuccessful. I checked my second test account to see if the alert was actually deleted or not, but the alert was there. Checked the alert id once again but it was correct. Here I forget to encode again the parameters into base64 encoding. Because the actual request was in the encoded format. Now, again replaced the another account alert-id, encoded the strings and sent the request. This time, the request was successful. Then I went to my second test account to see if the alert was actually deleted, and yes the list was empty.

Since the alert-id was numeric, it would be easy for an attacker to delete the job alerts of mass people with just using the intruder of burp suite. After all this, I made a detailed report to the team and they triaged my report with High (8.6) severity.

So, this was all about my IDOR finding. Thanks for reading till the end. You can also connect with me on LinkedIn.