Client Side API
# API Documentation
- /api
- /swagger/index.html
- /openapi.json
------------------------------------------------------------------------------
# Directory Searching
Https://domain.com/api/research/v1/price
- Try to retrieve back each path to see if possible to get information
- Check API Version (API, V1,V2,...)
------------------------------------------------------------------------------
# Http Verbs
Trying mutiples types of verbs to see if the endpoint allow other verbs
- GET
- POST
- OPTION
- PATCH
- PUT
- DELETE
- ...
*Don't forget that if it give a 500 error, this might meen that it need JSON data*
------------------------------------------------------------------------------
# Changing Content
- Trigger errors that disclose useful information.
- Take advantage of differences in processing logic (API may be secure when handling JSON data but susceptible to injection attacks when dealing with XML)
------------------------------------------------------------------------------
# Directory Enumeration
- Intruder ex: /api/user/update (Enum update path, to find maybe delete, add...)
- AMASS
- amass enum -list
- amass enum -active -d TARGET | grep api (OPTIONAL)
- Gobuster
------------------------------------------------------------------------------
# Identifying hidden parameters
PATCH /api/users/
{ "username": "wiener", "email": "wiener@example.com", }
GET /api/users/123
{ "id": 123, "name": "John Doe", "email": "john@example.com", "isAdmin": "false" }
This may indicate that the hidden `id` and `isAdmin` parameters are bound to the internal user object
From there, you might want to test adding the missing parameter to the Patch option and change the potential value that can be attribuated, an gain a feeling on what is accepted and what is not
Server Side API
Server-side parameter pollution occurs when a website embeds user input in a server-side request to an internal API without adequate encoding
- Override existing parameters.
- Modify the application behavior.
- Access unauthorized data.
------------------------------------------------------------------------------
# Testing for server-side parameter pollution
- GET /userSearch?name=peter&back=/home
- GET /users/search?name=peter&publicProfile=true
# Truncating query strings
- GET /userSearch?name=peter%23foo&back=/home
- GET /users/search?name=peter#foo&publicProfile=true
# Injecting invalid parameters (You can use an URL-encoded &)
- GET /userSearch?name=peter%26foo=xyz&back=/home
- GET /users/search?name=peter&foo=xyz&publicProfile=true
# Injecting valid parameters
- GET /userSearch?name=peter%26email=foo&back=/home
- GET /users/search?name=peter&email=foo&publicProfile=true
# Overriding existing parameters
- GET /userSearch?name=peter%26name=carlos&back=/home
- GET /users/search?name=peter&name=carlos&publicProfile=true
- PHP parses the last parameter only
- ASP.NET combines both parameters
------------------------------------------------------------------------------