• caglararli@hotmail.com
  • 05386281520

Information leakage from a API 404 response

Çağlar Arlı      -    12 Views

Information leakage from a API 404 response

Our consulting company has received a VAPT from a consulting company on behalf of a financial customer.

The application has an HR/group management module.

Normally employees are created by an asynchronous process, but in case this fails the application's admin should have access to UI and create a user along with their line manager.

There is API GET /api/v1/employees/lineManagers to list users that are eligible as line managers. And API POST /api/v1/employees to create a new employee. And there is API GET /api/v1/employees that basically lists all employees and is required by the management UI,

In order to create a new employee, one has to POST several parameters:

{
    "userid": "",
    "name": "",
    "surname": "",
    "lineManagerUid": "",
    ....
}

Now, if the user ID of the line manager is not existing or is not enabled as LM, the application will return 404 error because of Java's Optional.orElseThrow (from a programming perspective, we query the database for the user and check that it has all flags).

From a security standpoint, I'd like to understand why this is considered a vulnerability. Consultant say that one can alter the JSON payload as soon as they find a valid user ID (rate limiting is done at API gateway, so outside our scope), so that a 202 response means that the line manager ID is valid and 404 that it doesn't exist.

I wonder why they are focusing on that because users can be listed by requirement, you don't need to hammer the POST api to enumerate the possible LMs as soon as you can invoke the authenticated GET and obtain all users.

I don't also think that returning 400 other than 404 will fix the issue, as user enumeration is triggered when you can determine the existence or not of the targeted user.

Since the application admin can nominate another user as Line Manager of new employee, how do you fix the user enumeration vulnerability when you actually need to enumerate them?