The best-case scenario for an attacker is if attacks on an application can go unnoticed as this would give the confidence to carry out consecutive attacks on the same application which could provide enough time for the attacker to fully compromise the system. This would be possible if an application has insufficient logging and monitoring of suspicious activities and fails to alert the necessary parties on time.
An example of the exploitation of this type of vulnerability could include an application that has been attacked using a large-scale credential stuffing attack and millions of user credentials have leaked. Since there was little logging in the application, the administrators did not receive alerts of any suspicious activity, nor were they able to track down exactly what records have been a victim to the attack.
Another example would be a scenario where an access token with administrative privileges has been stolen and has been used to perform potentially harmful activities by an attacker (see Figure 8).
Figure 8: An attacker changing user role with the stolen access token
The owner of the access token, who finds out that the client has been breached suspects that access token might have been stolen and alerts the system administrator who immediately revokes the compromised token and issues the owner a new one.
However, it is now necessary to identify what activities have been carried out during the time the breach was not reported since the extent of the damage done to the system must be approximated. This would not be possible in this scenario since there has not been proper logging and monitoring mechanisms in place.
How can this be mitigated?
When API traffic is exposed via an API Gateway, API requests and response meta-data can be logged centrally and can be investigated to review any suspicious activity from the stolen access token which reveals the extent of damage and data altered by the attacker (shown in Figure 9).
Figure 9: An API Gateway is able to centrally log any activity from API Traffic
Real-time monitoring is also possible when exposing API traffic using an API Gateway. For example, in this case, Kate lives in the UK and the API Gateway is able to identify that primarily traffic from Kate usually comes from the UK based on the IP address of the device that is being used to run the application. Thereby allowing the API Gateway to recognize any anomalies by monitoring the changes in access patterns.
Assuming an attacker residing in Russia was able to steal the access token used by Kate and invokes the API, the API Gateway will instantly identify the change in the access pattern and flags the API request coming from Russia as suspicious activity, block that request and inform an administrator to take the appropriate action (to continue blocking calls from that IP address or to allow it if the IP address is validated to be from a legitimate user).
Figure 10: Suspicious activity being recognized and rejected by an API Gateway
The best API Gateway solutions also offer Bot Detection functionality and detailed logging and monitoring mechanisms, which further enhances protection against this type of vulnerability. Thereby emphasizing the importance of the role played by API Gateway solutions to overcome many modern day vulnerabilities and pro-actively protect your applications from them.
If you have any doubts feel free to ping me in Insagram . (__fazalurrahman__)
