Write up of the APISEC-LAB

Hello everybody this is the complete write up of the APISEC-LAB. This post will cover all the key vulnerabilities that must be found in the app. So lets get started with the bugs.

1. Mass Assignment

When the user registers itself for the portal, the default role is assigned to him which is driver role. although there is not such key specifying the role so using the mass assignment we can add the role and its value to org_admin which will give you the access of the admin.

2. BFLA :- Broken Function level Authorisation

This vulnerabiltity arises due to not authorising correctlty the function. The user is able to update the role of the user itself. there is no need of any admin.

3. Excessive Data disclosure

Here the API response from the server is exposing the sensitive data. here the hashed password and other things are being displayed.

4. Improper API version handling

This vulnerability is leading to the disclosure of all the user details. Providing the hashed password and their role details.

5. Business Logic

This vulnerability is system based error. when the input is not correctly handled. Here the quantity parameter is accepting the negative value. There is no validation on front-end and back-end for handling the negative value. This leads to increase in wallet value and purchasing the product for free.

6. Stored XSS -> Session gain -> Account Takeover

The driver can generate the ticket and using this functionality the attacker can send the malicious payload for xss. Also we can chain it to Account Takeover by gaining the session token value.

7. SSRF -> Internal system info disclosure

There is a functionality for adding the external link for web hook connectivity. Using this functionality the Attacker is able to read the data of running internal service.

8. Exposed JWT public key

On checking the available api-docs we get to see the exposed JWT public key which can be used to forge a new token and getting access of the account. Lets change the role using JWT for a user with driver role.

Use https://www.jwt.io/ to generate the new JWT Token.

9. Exposed JWT Token in Local Storage

This might feel not so critical on the first look. And this is correct if we report is alone but we have also found the stored XSS injection point using that we can call for local storage value { localStorage.getItem('fp_token') } through the xss and can get access to the account.

10. BOLA

Functionality for checking the trip is controlled by the trip id. which can be seen by any driver by changing the id whether he has completed the trip or not.

11. No token expiry / no revocation

The server is not verifying the expiry of token. Even after logout if the session token is captured using the stored xss then it can be reused any time after session logout the server is unable to verify it.

12. Password Reset token invalidation

We got the route for the password reset from api-docs. The user can generate the token and can use it to change or update his account password. A simple way to change the password. But here the catch is any one can generate the token for any email and can further use it to change the password of that email related account. The token can also be used again and again.

→ Opting for the token

→ Updating the Password

13. SQL Injection

When you read the app.js file https://localhost:4000/app.js you will get to see all the routes for the apis. On looking you get to see an api with some parameter to get some data from server

Using this endpoint to check for the sql injection. The server returns the query in error in json. The union based sql injection can be used to get the data from the data base.