Analyzing Low Risk API Testing Findings For WORKFLOW-24 Jira Ticket

This article delves into a low-risk API testing finding, specifically related to Jira ticket WORKFLOW-24, categorized under the racheli-test-org,2test discussion category. The issue stems from API testing performed on the POST /identity/api/auth/login route, which has revealed several low-severity vulnerabilities. This comprehensive analysis will detail the findings, their potential impact, and recommended remediation strategies to enhance the security posture of the API.

API Testing Details

Route: POST /identity/api/auth/login

This route is flagged as potentially sensitive and is associated with API testing findings, indicating areas where the API's security can be improved.

Introduced Through:

[services/identity/src/main/java/com/crapi/controller/AuthController.java](https://github.com/apiiro/crAPI/blob/main/services/identity/src/main/java/com/crapi/controller/AuthController.java#L56)

The issue originates in the AuthController.java file within the services/identity module, specifically at line 56.

API Declaration:

public ResponseEntity<JwtResponse> authenticateUser(@Valid @RequestBody LoginForm loginForm)

The API declaration reveals that the authenticateUser method handles user authentication, taking a LoginForm as input and returning a JwtResponse. This method is built using the Spring framework.

API Framework: Spring

Module: services/identity

The API in question is part of the identity service, which is crucial for authentication and authorization functionalities.

API Testing Findings

The API testing, conducted by AkamaiApiSecurityActiveTesting on November 28, 2024, at 12:26:23, identified several low-severity issues, along with one high-severity issue. Each finding is summarized below, along with detailed descriptions and recommended remediations.

Low Severity Findings

1. OpenAPI: Undocumented Fields in Response

Summary: The API endpoint returns fields that are not specified in the OpenAPI Specification (OAS) documentation. This discrepancy can expose the API to vulnerabilities and malicious activities.

Tested API route/method:

• Http Method: POST
• Route: /identity/api/auth/login

Description: The core issue here is the presence of undocumented fields in the API response. These fields, not being part of the official API documentation (OpenAPI Specification or OAS), create a significant blind spot. This lack of documentation means that developers and security professionals are unaware of these fields, making it difficult to predict their behavior or potential vulnerabilities. Attackers, on the other hand, can exploit this obscurity. By sending requests and analyzing the responses, they can identify these undocumented fields and potentially use them to gain unauthorized access to sensitive information or manipulate the system's behavior. Furthermore, the absence of documentation makes it challenging to maintain the API. As the API evolves, these undocumented fields may be inadvertently changed or removed, leading to compatibility issues with applications that rely on them. This can result in unexpected errors and system downtime. The severity of this issue is elevated when the undocumented fields contain sensitive data, such as user information or internal system details. The risk of data leakage and unauthorized access increases dramatically in such cases. Therefore, it is crucial to address this discrepancy promptly to ensure the security and stability of the API.

Remediation: To effectively address this issue, it is essential to ensure that the OpenAPI specification accurately represents the schema of the API assets. This involves a comprehensive review of the current OAS documentation, comparing it with the actual API responses. Any discrepancies found should be immediately rectified by updating the OAS documentation to include all fields returned by the API endpoint. This will provide a clear and accurate view of the API's structure and behavior. In addition to updating the documentation, it is imperative to implement continuous testing of your APIs. Regular testing allows for the evaluation of the accuracy of the specifications and ensures that they remain up-to-date as the API evolves. Automated testing tools can be used to automatically validate API responses against the OAS documentation, flagging any discrepancies for immediate attention. Furthermore, it is highly recommended to adopt a documentation-driven development approach. This means that the OAS documentation is created and maintained as an integral part of the development process, rather than an afterthought. By documenting the API upfront, developers are forced to think about the API's structure and behavior before implementing it, reducing the likelihood of undocumented fields. This proactive approach to documentation helps ensure that the API is secure, properly documented, and easy to maintain over time.

2. Username Enumeration

Summary: The API is vulnerable to username enumeration, allowing attackers to determine if a particular username exists in the system.

Tested API route/method:

• Http Method: POST
• Route: /identity/api/auth/login

Description: Username enumeration is a critical vulnerability that allows attackers to discern valid usernames within a system. This is achieved by analyzing the subtle differences in the system's response to login attempts. For instance, if the system provides a distinct error message for an invalid username compared to an incorrect password, an attacker can exploit this difference. By systematically trying various usernames and observing the responses, they can compile a list of valid accounts. This list then becomes a valuable asset for targeted attacks, such as password brute-forcing or phishing campaigns. The danger of username enumeration lies in its ability to transform a generic attack into a highly focused one. Instead of randomly attempting logins, attackers can concentrate their efforts on known usernames, significantly increasing their chances of success. Moreover, once a username is confirmed, attackers may gather additional information about the user through social engineering or other means, further enhancing their attack strategy. The consequences of successful username enumeration can be severe, ranging from unauthorized access to sensitive data to complete account takeover. Therefore, it is essential to implement robust countermeasures to mitigate this vulnerability and safeguard user accounts.

Remediation: To effectively mitigate the risk of username enumeration, the primary recommendation is to implement a generic response message for all login requests. This means that regardless of whether the username is invalid or the password is incorrect, the system should return a consistent error message, such as