API Attacks - Skills Assessment
According to the challenge description, the Inlanefreight E-Commerce Marketplace company has already fixed all the previous API vulnerabilities and released a v2 version. However, the admin believes there may still be a new vulnerability in this v2 release, so they asked us to perform another retest.
This time, they provided us with a customer account. After logging in and checking the assigned roles, I noticed that this account has two permissions: Suppliers_Get and Suppliers_GetAll.
Alright, let’s see what kind of information we can access with these two roles.
Surprisingly, with the Suppliers_GetAll role, I was able to retrieve a large amount of information. What makes this API even more dangerous is that it exposes the suppliers’ security questions.
LoL — with information like this, if the application also has a weak password reset mechanism and login without MFA, there’s a real possibility that an attacker could take over user accounts.
Alright, let’s take a closer look at the response data and see if there’s anything else interesting exposed.
When I checked the supplier password reset API. I only needed to provide the user’s email, the securityQuestionAnswer, and a newPassword value in order to reset the account’s password.
After reviewing the response list, I noticed that around five supplier accounts were using very simple security questions related to colors.
If the application also lacks a proper rate-limiting mechanism, then realistically, an attacker could brute-force those answers and potentially take control of user accounts within just a few minutes.
Alright, time to brute-force the security question answer. I’ll use Burp Suite here since the number of possible values is fairly small, so there’s no real need to use ffuf for this one (and honestly, I’m too lazy to build the command).
For the list of color names, you could even ask GPT to generate a quick wordlist. After running the attack, I was able to identify a successful password reset request.
Okay, after resetting the password, I logged in using the supplier account we had just taken over. When checking the supplier/current-user endpoint, it now returned the supplier user’s information, whereas earlier during testing it only returned an error. The reason was simple: initially we were using a customer account, so it could not access the current supplier information.
The challenge requires us to retrieve flag.txt, so I decided to test the supplier CV upload functionality and inspect how uploaded files were being handled.
After uploading a CV and reviewing the response, I noticed something interesting: The web API stores file paths using the file URI scheme, which is used to represent local file paths and allows access to files on the local filesystem.
Next, I used the update current supplier endpoint. This endpoint allows us to modify the file path of the CV we previously uploaded.
So I tried changing the CV file path to point to flag.txt instead. The response returned true, which indicated that the update was successful.
Now there was another endpoint called get supplier cv as base64. I decided to call this endpoint, and if our assumption was correct, it should return the contents of flag.txt encoded in Base64.
And boom — it successfully returned the contents of the file.
This is a serious issue in API development. From the very beginning, we saw that excessive data exposure in API responses unintentionally leaked users’ security questions. If a normal user can access information like this, they may be able to abuse it for password reset attacks. As demonstrated in this write-up, sensitive information exposed in responses should always be minimized to only what is strictly necessary.
In addition, exposing internal server file paths is also a major concern, since attackers may leverage this information to test vulnerabilities related to SSRF or local file access issues.
On top of that, a proper rate-limiting mechanism should also be implemented. As we saw with the password reset endpoint, I was able to brute-force the security question answers freely without encountering any timing restrictions or protection mechanisms. And that was only using Burp Suite CE – using faster tools or automation frameworks could make the attack even more efficient.