APIs, the one’s acting as helpers/waiters to the applications, bringing in stuff the user requested.
All dynamic websites, contains APIs. even the classic SQL is API testing.
find out which APIs are being used - to map out the attack surface. identify the API endpoints.
find out
the input data it processes, compulsary and optional parameters
types of requests it accepts, HTTP methods and media formats
Rate limits and authentication mechanisms.
Documentation
sometimes doucmentation for the application might be available and thats easier to understand all the APIs being used and to map out the attack surface.
Discovery -
but sometimes its not available, directly. so crawl the application normally and look for the documentation endpoints. eg: /api , /swagger/index.html, /openapi.json , /api/swagger/v1 , etc.
finding documentation can be hard task sometimes, an easy way is to use Burp Scanner to crawl and audit OpenAPI documentation or some other in JSON/YAML format. if its available in OpenAPI documentation then [https://portswigger.net/bappstore/6bf7574b632847faaaa4eb5e42f1757c] - this can be used to parse it.
Another way to create your own documentation
Open a clean window>Network Tab. Clear the previous stuff and do the “Preserve log” and “Disable cache“ check. and then record your walk-through of the app and try to save/export it as an HTTP archive (HAR) file. or Install the https://github.com/nccgroup/LoggerPlusPlus in burpsutie. Install the extension and log all the traffic.
highlight the requests you want to export, right-click on the log pane, and select Export entries as... > Export # entries as HAR
use the HAR file with tools like https://github.com/alufers/mitmproxy2swaggerto reverse-engineer your target REST APIs via captured traffic in Burp Suite... outputting the results into an OAS3-compatible API spec doc
How to craft your own rogue API docs for a target when they don't exist
https://danaepp.com/how-to-craft-rogue-api-docs-for-a-target-when-they-dont-exist
Discovering API secrets & endpoints using APKLeaks
https://danaepp.com/discovering-api-secrets-endpoints-using-apkleaks
Content-Types
APIs expect data in certain format, and will respond on the Content-Type that’s being asked in the request. Changing the content-type may result in errors and vulnerabilites can be discovered
https://portswigger.net/bappstore/db57ecbe2cb7446292a94aa6181c9278 - BApp to do convert automatically
APIs can support hidden parameters and these tools help in finding them:
https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943 and https://portswigger.net/burp/documentation/desktop/tools/engagement-tools/content-discovery
Mass Assignment
sending params in the requests that were never intended to be processed and it gets assigned to something.
some frameworks automatically bind request parameters to fields on an internal object.
Identifying hidden params
eg: PATCH /api/users/
{
"username": "wiener",
"email": "wiener@example.com",
}
and a simultaneous GET call of GET /api/users/123 returns:
{
"id": 123,
"name": "John Doe",
"email": "john@example.com",
"isAdmin": "false"
}
from the GET call we got to know that, the hidden id and isAdmin params are bound to internal user objects.
Testing Mass Assignment
since we now know that id and isAdmin params, try to update those params with
PATCH request:
{
"username": "wiener",
"email": "wiener@example.com",
"isAdmin": false,
}
also, try sending an invalid value in the isAdmin param like:
{
"username": "wiener",
"email": "wiener@example.com",
"isAdmin": "foo",
}
if any of it behaves differently, it means invalid value impacts the query logic but the valid value does not. and this means that param can be updated.
set the isAdmin param to true and exploit it.