Insecure direct object references(IDOR) bug

[sujan060]

Hi team,

While testing for the scope asset I have discovered a security issue on your web app. I hope you will take time to into this report and validate this issue as soon as possible. It will help me to research further more.

Affected Webapp: https://affiliates.shiftcrypto.ch/

Summary:

Insecure Direct Object References (IDOR) occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files. Insecure Direct Object References allow attackers to bypass authorization and access resources directly by modifying the value of a parameter used to directly point to an object. Such resources can be database entries belonging to other users, files in the system, and more. This is caused by the fact that the application takes user supplied input and uses it to retrieve an object without performing sufficient authorization checks.

There is a feature to create a tracker in the mentioned site. While creating a tracker the web application validates user authorization through user id associated with the user account. When we replace the userid the web application doesn't check further any permissions it leads to creating of unauthorized trackers into the victim account. Instead of denying our request.

note: The userid consists of unique code. So, It may affect the severity of the issue. Because of complexity to find the userid. But still this is considered a security issue in other programs too.

References: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References

https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html

Impact:

An attacker will be able to create a tracker into the victim account. Weak authorization or privilege.

Steps to reproduce:

1. Login a two different account in two different browsers.
2. Capture the userID of both account.
3. Now go to create a tracker. Intercept the HTTP REQUEST using any tool like burp.
4. Just change the userid of victim it will create a tracker to the victims account. Hence web application doesn't deny our request when we send any unauthorized request to the server.

Please let me know if you have any questions about this issue. I will be glad to provide more information as much as possible.

Best regards,

Security Researcher

Sujan

[valeriansaliou]

Thanks for the report, I'll handle it a bit later next week or in 2 weeks.

[valeriansaliou]

I've reviewed your security report, and I could not find any weak point where a given user could alter another user's data.

You've replayed a request using Burp, while using HTTP it would be a vulnerability, nowadays all websites use HTTPS, and thus traffic cannot be altered or captured.

Regarding the user_id cookie, it is encrypted per-user using a configured secret key, that changes per Raider setup. We use Rocket's private cookie methods to store and retrieve encrypted and authenticated cookies using this secret key: https://api.rocket.rs/v0.4/rocket/http/enum.Cookies.html#private-cookies

A random user thus cannot craft a cookie containing an user identifier in the clear.

Thus, this security issue is a non-issue.

[valeriansaliou]

Raider code ref regarding authentication: https://github.com/valeriansaliou/raider/blob/master/src/responder/auth_guard.rs#L53