Wizer CTF #32: Tell me who your friends are #2

Link to challenge: CTF #32

Goal

In this challenge, we're exploring another example of a typical IDOR vulnerability.

Description of code

The code in this challenge showcases a typical players and friends/followers model. The relevant endpoints are: `/player` which runs a simple select query to fetch a player record by ID from the database, and `/friends` which selects the friends of a specific player by ID.

What’s wrong with that approach?

The issue with this approach is that the `/friends` endpoint does not validate the user making the request. This means that any user can request the friends of any other user by simply changing the ID in the request. This is a classic example of Insecure Direct Object Reference (IDOR) vulnerability, where an attacker can access data that they should not have permission to access. The only question here is how do we find the ID of the specific player that the challenge is asking us to get?

What would a successful IDOR attack look like?

A successful IDOR attack would involve an attacker changing the ID in the request to the ID of the target player. For example, if the attacker knows the ID of the player they want to target, they can simply make a request to `/friends?playerId=<target_player_id>` and retrieve the friends of that player, that's the IDOR. To get the ID of the player we want to target, we can start scanning down the tree of friends, first `James Robins` direct friends, then each of their friend's friends etc. In this case, within two hops from `James Robins` account, you will find the target player `Lee Wung`.

So what?

This vulnerability poses a serious risk as it allows attackers to access sensitive information about other users without their consent. In this case, the damage might seem limited, since there's not much information in the data it stores. However in the wild, an attacker could potentially gather information about a target player's friends, which could either be sensitive, or used for social engineering attacks or other malicious purposes. Scammers often use Personally Identifiable Information (PII) to build trust and mislead their victims, hence PII is considered sensitive information which is explicitly examined for compliance purposes.

Main Takeaways:

• IDORs pose a real risk, never skip authorization:
  Always validate the user making the request and ensure that they have permission to access the requested resource. Implement proper authorization checks to prevent unauthorized access to sensitive data.
• Obscurity isn't security:
  Just because you think that an attacker won't find a way to access a resource doesn't mean they won't. Always assume that attackers will try to access any resource they can, and implement proper security measures to protect against unauthorized access. The UUID format, which at first seems like a good hiding mechanism because it's very hard to guess, is not a good security measure.
• Code security is measured across the entire app:
  Always consider the security of your entire application, not just individual functions or endpoints. A vulnerability in one part of your application can lead to security issues in other parts, so it's important to take a holistic approach to security. In this case, the `/player` endpoint is not exploitable individually, but given the `/friends` endpoint provides access to other player IDs without proper authorization, the `/player` endpoint becomes a potential attack vector as well.

Code Wizer!