I decided to browse the web and create my account, so I decide to use Mozilla Firefox OAuth authentication method to create my account for the first time on GetPocket.

Once I access my GetPocket account you will see that it is a normal Regular account with no privileges 😔.

I thought 🤔 How could I get a free premium account?

Then I remembered 💡 I had done some online shopping and had a Visa Gift Card 💳 No Funds and said why not use it to load GetPocket Premium account. I should give not accept it, as most of these web applications employ payment processing like Stripe, which uses a feature called https://stripe.com/radar radar that allows to detect this kind of abuse.

So I opened my Burpsuit https://portswigger.net/ my Favorite Tool 🔨🔥 to hunt bugs. Once I got the Request I sent it to the Repeater and added the following line X-Forward-For: 127.0.0.1 and hit Send ️

Served Accepted the Request 🥳🎉200 OK

Stripe Payment Processor bypass and gave me a purchase confirmation order to be reflected in email ********@gmail.com

I could see how the user account is no longer the same, it has other functions, as it is now a premium account 🙃

Apparently, Stripe’s Radar feature is not Enabled, which allowed this abuse. Knowing all this, I proceeded to inform Mozilla Security Team to report the security flaw to them, and thoroughly investigate the issue and take the necessary steps to correct it. The Mozilla Security Team responded very quickly and were very nice.

The Bug, Turned Out to be a Duplicate.

Let me explain a little what is an IDOR (Insecure Direct Object Reference) is. This type of bug allows an unauthorized user to change the value of a parameter to access an object for which they are not authorized.
Example: Let’s say you are using Google Drive 📁 and you are looking for a Document, Above in the URL you will see this https://drive.google.com/document/101 the 101 is an ID or identifier of the Document you are standing on.

If you change the address and replace 101 with 102 you will almost certainly see an error on the screen. The error will be something like “document not found” or “you do not have permission to view this document”. What happens in this example is that Google Drive uses the last part of the address to identify each document it stores for its users. Document 101 belongs to you, so you can view it, but document 102 is probably from another user, so you don’t have permission to view it.

Basically, to be more specific, the API that the Application uses has a bug that allows you to modify a parameter of the purchase order that allows you to see the information of the users, as I explained in the previous example. If your personal information was visible in the address ending in 101, and you change that address to end in 102, you would see another user’s information.

Now that you know how it works, let’s get started!🤖

One Day After ordering fast food through the app it occurred to me to check if there was any user data leakage, so I turn on my 🔥 Burpsuit and the first thing I do is change the price of the product purchase to $0 The server accepted the request 200 OK.

Ok 🤔 I can get free food?

I decided to investigate further 😎 🔎 and I checked my past Purchase Orders and noticed that when I suddenly changed my orderId=321448 to orderId=321444 I see that the server accepted the request 200 OK.

Bingo ✅

Here you can see the Customer user as well as the delivery person in charge of that order, you can see all the personal information as well as some URL with photos of the delivery person etc.

Data-Exposed

— — — — — — — — — — — — — — — — — — -
• CostumerName
• CostumerEmail
• PhoneCustumer
• CostumerAddress
• Costumer Comment to deliveryman
• Username deliveryman
• Email deliveryman
• Phone deliveryman
• Description of the deliveryman vehicle (Plate, Model, Color, Brand)
• Order Tracking URL
• Photo ID deliveryman

— — — — — — — — — — — — — — — — — — — — -

APIKEY 🔑 Token Hardcoded Exposed

Some 📱 Android / iOS Apps store Token that could be abused to leak a number of harmful data, some keys are harmless and are required to be in the app, for example: Google, Mapbox Apikey while there are others that could expose harmful data, which could affect the company. The 🛠 tool used to reverse engineer Android apps and discover secret tokens stored in them is accessible online. APK-Tools https://www.kali.org/tools/apktool/ is one of them.

After reverse engineering the file.APK 🔄🙃 I found a string.xml file that stores the global variables of the app

As you can see, the string.xml file has secret key 🔑 to access external services to the application, one that caught my attention was the STRIPE_SECRET_KEY. Basically, Stripe is an online payment processing system for 📱 Android / IOS / WEB apps that makes it easy to make 💰 payments.

To check ✅ if a Tokens 🔑 is alive, I recommend going https://github.com/streaak/keyhacks

Since we see that the STRIPE_SECRET_KEY is valid 💰 we check with the Postman tool to verify the scope of the TOKEN, for this I use a JSON Format Collection offered by Stripe for Postman https://github.com/stripe/stripe-postman this allows me to do pushes and pulls from the official Stripe account of hungrybite.com which can be potentially devastating. To verify if a Stripe access key is alive, you can use the Stripe API method “retrieve”. This allows you to retrieve information about a specific object, such as a Stripe account. If the call succeeds, it means that the provided access key is valid.

As you can see, many developers frequently use tokens and forget the 🔑 access token in public repositories, this is potentially dangerous. To mitigate this problem, it is recommended not to leave API access tokens in public repositories. To fix this issue, I recommend revoking that token and generating a new one. It is also important to periodically change tokens, to prevent them from being stolen.