Today, we’re about to discuss one such twist — an issue that holds the power to disrupt the balance between security and access. In web development, every line of code, every interaction, and every component matters. So read this with full attention.

There are many moving parts, and two main players are the frontend (the part you see) and the backend (the hidden brain). They usually work together smoothly to make websites and apps work like a charm.

Understanding Target: Examcat

Examcat(virtual name of private program) It’s not just any website; it’s a platform created for developers and businesses who want to make money from their mobile apps.It helps them manage things like subscriptions and in-app purchases in their apps through api.

The StART

In examcat there is a feature of adding collaborators , Collaborators have access to create API keys. These are like special keys that let certain programs access specific parts of the website.

Adding to the mix, there’s another layer of complexity. Collaborator roles and API key permissions are like two different languages. Even if someone who created an API key is no longer in charge, that API key still works. It’s like a ticket that never expires, no matter who used to hold it.

It means if the collaborator is removed he/she can still use that APi key but this is not the main concern of this report. Admin can change the api permissions but the main concern is the admin cannot able to change the permission of API Key because of the issue.

The Bug

When an collaborator creates an API key with read and write access to project_configuration and projects by making a small change /internal/v1/developers/me/projects/988791cd/api_keys permission parameter , the API key will continue to have read and write access even if the admin is removed and the permissions are changed to read only or none.

Steps To Reproduce:

• Create an API key as an collaborator.
• In the request body permissions parameter, replace project_configuration and projects with *.
• Click “Create API Key”.
• Remove the admin who created the API key.
• Change the API key permissions to read only or none.
• Try to access project_configuration or projects using the API key.
• YOu can still be able to perform the action thorugh the API key even after changing the permissions.

POST /internal/v1/developers/me/projects/988791cd/api_keys HTTP/2
Host: api.examcat.com
Cookie: 
Content-Length: 94
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
Accept: application/json
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Sec-Ch-Ua-Mobile: ?0
{"label":"test","api_version":"2","permissions":["*:*:read_write"]}

The Twist: Frontend vs. Backend

Because i use in API request `*:*` in the instead of project_configuration and projects it give the full access to that API key. The backend of the platform supported wildcard permissions like ::read or ::read_write, offering broad access across domains. However,

The frontend struggled to render and update these wide-ranging permissions accurately. It display “No access” by default, even when API keys had valid permissions. And when users attempted to change permissions, the frontend faced challenges and show the api key has none or default permissions.

So it is hard to catch this issue by admin he/she would think, he/she change the permission. So that API has none access permission. But deep down that API key still has all the access.

The Bounty

Now, you might wonder, what’s the buzz around this discovery? Well, here’s the exciting part! this frontend issue didn’t just technical puzzle; i also earned a bounty of $250 for this find.

Takeaway

Remember, even the smallest issue in a web app can lead to valuable discoveries. So, stay curious when using websites — you might find something interesting that helps make some money for that well-deserved wishy.

Leave some claps if you enjoyed this read, leave your feedback in comment and consider following me for more exciting findings.

Find me on Twitter: @a13h1_

Keep Supporting, Keep Clapping, Keep Commenting.