1. Don’t ignore encoded and hashed IDs
if the application is using a hashed/ randomized ID, see if the ID is predictable. Sometimes applications use algorithms that produce insufficient entropy, and as such, the IDs can actually be predicted after careful analysis.
GET /api_v1/messages?conversation_id=SOME_RANDOM_ID
GET /api_v1/messages?user_id=ANOTHER_USERS_ID
2. If you can’t guess it, try creating it
object reference IDs.
3. Offer the application an ID, even if it doesn’t ask for it
id, user_id, message_id,...
GET /api_v1/messages
// What about this one? Would it display another user’s messages instead?
GET /api_v1/messages?user_id=ANOTHER_USERS_ID
4. HPP (HTTP parameter pollution)
HPP vulnerabilities (supplying multiple values for the same parameter) can also lead to IDOR. Applications might not anticipate the user submitting multiple values for the same parameter and by doing so, you might be able to bypass the access control set forth on the endpoint.
// if
GET /api_v1/messages?user_id=ANOTHER_USERS_ID
// try this
GET /api_v1/messages?user_id=YOUR_USER_ID&user_id=ANOTHER_USERS_ID
// or this
GET /api_v1/messages?user_id=ANOTHER_USERS_ID&user_id=YOUR_USER_ID
// Or provide the parameters as a list
GET /api_v1/messages?user_ids[]=YOUR_USER_ID&user_ids[]=ANOTHER_USERS_ID
// The value of a parameter is used directly to retrieve a file system resource
GET /showImage?img=img00011
5. Blind IDORs
Information may be exposed in other places: in export files, emails, and perhaps even text alerts.
6. Change the request method
try instead: GET
, POST
, PUT
, DELETE
, PATCH
…
A common trick that works is substituting POST
for PUT
or vice versa.
7. Change the requested file type (content type)
For example, try adding .json
to the end of the request URL and see what happens.
8. Transform numerical values to arrays
{"id":19} → {"id":[19]}