Hallo fellow researchers,

Myself, Rafi Ahamed. I am a Cyber Security Researcher from Bangladesh. I love to do things differently. Anyway, without further ado let’s get to today’s topic.

Today’s topic is all about exploitation of API endpoints using AuthToken. Not about finding one.

Many of us finds AuthToken in our recon process but due not being able to show any impact this critical finding often gets rejected. I got rejected a few times myself.

API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API.

Let’s assume you find an AuthToken or API token of any user in your recon process. Simply reporting that will give you a Not Applicable in most cases.

Recently I was testing a private program in Bugcrowd and in my recon process I found a AuthToken which you always get your hands on. But the tough part was exploiting it. First of all, the program didn’t provided any credentials for testing and there wasn’t any way to Sign Up either. So, I had no idea how their infrastructure actually works.

In my recon the token that I found was an AuthToken (written in the code) which could be an alternative to Authentication Bearer token that an API use for Authentication. Now, I got a hint that the token was more like an API token. But I had no idea how their API infrastructure works as I had no access to any user account or anything. So, I gave up on it.

The next when I was testing another web application, I saw an API call when updating the user info. I thought may be I can use this API call to exploit yesterday’s one. So, I send that request to Repeater using Burp. Changed the Host & request endpoint with one that I found in my recon process. This gave me a response like below:

I got 403 forbidden. But this gave us some info that what Headers are missing. Then I added the token that I got using the Header Name that the response showed. This gave me a response like below:

500 Internal Server Error!!

That means I got a connection to the API. As you can see, the request is a POST request and there are no POST data in the request. That’s why the application was showing 500 Internal Server Error. Then I recon a little bit more & got some POST data that could use to test the endpoints. I sent the request again adding the POST data and I was shocked to see the response.

I got access to 100 client’s data. That moment I was like Boom🤯

I quickly reported the bug to Bugcrowd & got triaged as P1 along with a nice 4digit bounty.

Reported: November 10th.

Not Applicable: November 13th.

Triaged: November 13th.

Resolved: November 14th.

Hope you guys enjoyed this one . PM me at Facebook or LinkedIn anytime if you have any questions.