CSRF Bypass Combined with IDOR To Complete Account Takeover!

Welcome everyone,

Continuing the chain series, today we have a light chain.

CSRF Bypass + IDOR To Account Take Over

First, let’s take a quick look at the website.

I’ll explain the nature of the website in general. We can consider the website as providing services like shopping, and the nature of the site includes sensitive services.

I started examining the website, and at first, I focused on anything related to authentication, such as changing the email and more.

So I started with the update email function.

And the first thing that caught my eye was the “user_id” parameter in the request body to update email.

I tried to change the parameter to another account number, but unfortunately, it returned a Response 401 unauthorized.

I tried to bypass verification in several ways:

3. I tried adding special characters like

Despite my several attempts, none of them worked, which was unfortunate. However, I didn’t stop there.

From here, I forgot about the IDOR and continued my testing

After attempts with the update email function, I noticed something, which is that the csrf_token value changes with each Request.

This led me to search for any specific patterns or files in the client-side JavaScript that might contain alg to generate the CSRF Token, but unfortunately, I couldn’t find anything.

Undeterred, I proceeded to test the CSRF token for possible bypasses. I tried the following techniques:

However, none of these attempts succeeded either.

Guess what? Did I stop? Nope.

Then, an idea struck my mind: generating a new CSRF token but not using it immediately. The plan was to perform an update email request, capture the token value, and then drop the request. This way, the CSRF token would remain valid.

I took the token, created a CSRF script, and embedded the token within it. I tested it with my secondary account, and the first thing I noticed was that the error response changed.

Instead of an “Invalid token” error, I received a 401 Unauthorized response which matches the IDOR protection.

Sounds interesting right? (;

Now, I knew the CSRF bypass was working. However, the user_id parameter needed to match the victim’s user account. So, the next step was to obtain the user_id.

Fortunately, within the same website, I had discovered Stored XSS. This allowed me to create a simple script that could fetch the user_id.

However, this method required minimal interaction from the user, reducing the severity of the vulnerability and likely resulting in a smaller reward ):

To overcome this, I combined the CSRF script with a script that simultaneously guessed multiple user_id. As mentioned earlier, user_ids were easy to guess.

So, here’s a little recap of the steps I took:

So I tested the CSRF script with my secondary account, and I was able to change the email to any email!I desired. Hence, I successfully bypassed the CSRF protection and the user_id validation altogether!

Now, by simply going to the password reset page and entering the email I changed to the victim’s email, I could achieve a full account takeover!

In the end, Keep in mind having protection doesn’t mean you’re fully protected (;

I hope my explanation was clear.

If you found it helpful, don’t forget to Like, Repost, and share your thoughts in the comments (;

twitter\X: https://twitter.com/omarzzu/

Thanks for your Reading!