Hey guys. Actually, this is the 2nd part of the vulnerability which we discussed in the earlier post. You can read that post from here. Now if you read the post, you will get to know that we have discussed the IDOR which we got in the e-commerce application.

What is this 2nd part all about?

So let us explain it in an easy to understand manner. What are the normal steps when you try to change your password on Facebook?

• You chose the option of ‘Forgot Password’.
• A link is sent to your mail id.
• You reset your password using that link.

Now did you ever try, again revisiting that link? Do you think that again revisiting that link will help you to reset your password?

Then the simple answer to this NO. It won’t help you to reset the password because the link gets expired after one use. The reason for that is if someone gets access to your emails anyhow, he/she can change the password if the link doesn’t get expired. That is why there is always a token in the links and if you check it, you will find that the token gets changed with each “Forgot Password” request.

But the vulnerability in our case was slightly different than that.

The way the application was working that it will send an email to the user for notifications when he subscribed anything.

The link in the mail would look something like this:
http://www.xyz.com/ticker/management/771255762/admin

Now when we unchecked all the subscriptions and again visited this link, it said that the link has expired or the URL contained an error which was the perfect way the application should work.

When we again subscribe any item, we got an email with a link something like this:

http://www.xyz.com/ticker/management/978975762/admin

As you can notice, the identifier got changed i.e the tokens we were talking about earlier.

Here lies the vulnerability. As we used the previously expired link again now, we can see the different subscriptions and that even the new ones. It was not that the link was showing us the cached page. We were able to see the latest subscription for the user and we can again uncheck some of his subscriptions and play around with it. This was quite an unusual bug for our team but it was a well-found bug.

The major and the most CRITICAL problem of this bug is if an attacker can guess an identifier for once, then the user is doomed. He can just save this identifier and whenever he tries to use this and finds the link is expired, it will mean that the user hasn’t subscribed to anything for now. But as soon as the user subscribes anything, the attacker will again be able to see the user’s subscription and has full WRITE access to it.

Final Points

So the IDOR mentioned in the previous post along with this case of the link not expiring even after another link is issued was a HIGH priority vulnerability for the e-commerce company.
If the application has been properly tested and verified, problems like this shouldn’t have existed in the start i.e. the issue of non-expiration of links for quite a number of days.

This was all for this two-part post which was quite related to each other. As we have already mentioned before, issues like this are very easy to find and just needs a keen sense of open eyes. So this was all for this time. Hope you all learned something out of this and learned to always check the link in the emails cautiously because that can open a whole new door of possibilities for vulnerability finding. Until then, Keep Learning and happy Hacking..!!!!

‍