Vulnerable eCommerce API is a simple Golang web application that contains an example of a Broken Access Control vulnerability and its main goal is to describe how a malicious user could exploit it.
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access to other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.
The main goal of this app is to discuss how Broken Access Control vulnerabilities can be exploited and to encourage developers to send secDevLabs Pull Requests on how they would mitigate these flaws.
To start this intentionally insecure application, you will need Docker and Docker Compose. After forking secDevLabs, you must type the following commands to start:
cd secDevLabs/owasp-top10-2017-apps/a5/ecommerce-apimake installThen simply visit localhost:8888 ! 😆
To properly understand how this application works, you can follow this step:
- Try registering a user and log in!
Now that you know the purpose of this app, what could go wrong? The following section describes how an attacker could identify and eventually find sensitive information about the app or its users. We encourage you to follow these steps and try to reproduce them on your own to better understand the attack vector! 😜
In order to better understand how this API works, two users, user1 and user2, were created as shown below:
curl -s -H "Content-Type: application/json" -d '{"username":"user1","password":"pass"}' http://localhost:8888/register curl -s -H "Content-Type: application/json" -d '{"username":"user2","password":"pass"}' http://localhost:8888/register
Or using web interface:
The users created above are registered on MongoDB and we can get their userID through the following curl commands:
curl -s -H "Content-Type: application/json" -d '{"username":"user1","password":"pass"}' http://localhost:8888/logincurl -s -H "Content-Type: application/json" -d '{"username":"user2","password":"pass"}' http://localhost:8888/login
This can also be observed via the web interface. In the web interface it is possible to verify that after completing the login form, two requests are made to the API.
Having both userID, we can verify that the route "GET /ticket/:userID" does not validate if the request was made by the same user or someone else without the proper permission, as shown by the image:
curl -vvv http://localhost:8888/ticket/GUID
How would you mitigate this vulnerability? After your changes, an attacker should not be able to:
- Access other users' tickets.
[Spoiler alert 🚨 ] To understand how this vulnerability can be mitigated, check out these pull requests!
We encourage you to contribute to SecDevLabs! Please check out the Contributing to SecDevLabs section for guidelines on how to proceed! 🎉