Introducing Credential Stuffing Detection
Introducing Credential Stuffing Detection
Introducing Credential Stuffing Detection
Introducing Credential Stuffing Detection
Introducing Credential Stuffing Detection
Introducing Credential Stuffing Detection
Close
Privacy settings
We use cookies and similar technologies that are necessary to run the website. Additional cookies are only used with your consent. You can consent to our use of cookies by clicking on Agree. For more information on which data is collected and how it is shared with our partners please read our privacy and cookie policy: Cookie policy, Privacy policy
We use cookies to access, analyse and store information such as the characteristics of your device as well as certain personal data (IP addresses, navigation usage, geolocation data or unique identifiers). The processing of your data serves various purposes: Analytics cookies allow us to analyse our performance to offer you a better online experience and evaluate the efficiency of our campaigns. Personalisation cookies give you access to a customised experience of our website with usage-based offers and support. Finally, Advertising cookies are placed by third-party companies processing your data to create audiences lists to deliver targeted ads on social media and the internet. You may freely give, refuse or withdraw your consent at any time using the link provided at the bottom of each page.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
/
/
API Security, OWASP, Attacks, Vulnerabilities

Insufficient Logging and Monitoring API10

Introduction

API10:2019 Insufficient Logging & Monitoring

Threat agents/attack vectorsSecurity weaknessImpacts
This vulnerability can not be exploited in its own right but what it does is help any potential attacker stay unnoticed. Depending on how much of the logging and monitoring is insufficient, the attacker can either stay unnoticed for longer or even not be noticed at all.Should anything happen on our system that needs investigation, we have no way of doing so if our logging and monitoring are insufficient and we probably would not even know we'd have something to investigate because of the insufficient monitoring.If we do not implement sufficient logging and monitoring, attackers are free to take their time and investigate the situation before they strike and even after striking, we would have no way of either knowing or following up on the attack.
Insufficient Logging and Monitoring API10

What is Insufficient Logging & Monitoring?

The title already says a lot but this vulnerability is a bit more complex than it was at first sight, of course the API is vulnerable if it does not create any log entries or when the log level is set incorrectly but we should not neglect to also check whether or not the contents of the log messages are what is expected and that they contain enough detail.

Insufficient Logging & Monitoring

A second aspect that is a bit harder to control is the log integrity, for example a malicious user might insert a special character that when written to the log breaks it. This is known as log injection and it could nullify all the logging efforts made.

When we finally have a clear plan of what to log, when and in what environment we need to ensure we are monitoring these logs, failure to do so would result in a massive decrease in the efficiency of our logging efforts.

Monitor check system

Monitor everything, not just the logs but make sure you monitor the APIs and the infrastructure as well.

How does Insufficient Logging & Monitoring affect business?

The impact from a business perspective can be seen in several aspects. To start with confidentiality since often logs contain personal information that the victim would rather not share with the world. You really want to protect the logs from any attackers as this can have a severe impact.

For that same reason we should ensure that any data that goes into the logs is sanitised to the same level of scrutiny as other vulnerability types like XSS for example. A log pollution attack can nullify our attempts to log proper, sanitized and sufficient data.

In any case if we do not have sufficient logging and an attack does happen, we have no real way of tracing the call.

Though it may be important to log things, we should not go overboard as every log entry has a cost to it in the form of resources, this is why it's so important to pick exactly the right amount of logging. If you log too much or don't put rate limiting on logging endpoints an attacker could perform a DoS attack by consuming all the resources the server has to log their calls.

Lastely, should an external audit ever happen, we would have no way of proving our true intentions due to missing audit trails.

Example Attack Scenarios

A log entry might be in CSV form, if the attacker knows this, they might insert a malicious character such as a comma character ( ,) which the CSV log will interpret as a new column thus breaking the code and the logs. Especially if the logs are being monitored since this might break the monitoring tool as well which is expecting a certain format but it will have lines with too many columns.

name,lastname,email
test,test,test@test.com
test2,test2,test@test.com
test3,te,st3,test@test.com

A second example would be an attacker gaining access to a system and being able to get customer's data for 9 years without alerting any of the monitoring tools. What's really scary is this happened a while ago (https://healthitsecurity.com/news/insurer-dominion-national-reports-server-hack-that-began-august-2010).

Preventive measures against Insufficient Logging & Monitoring?

  • We should log any authentication calls and at a minimum failed calls. This can be a 403 forbidden status code but also any input validation.
  • How we log is also partially decided by the log management systems since the logs we create should be able to be consumed by said systems. The formats of our logs should match the expected format for the management solution.
  • Log should be treated with the utmost respect towards people's privacy in mind, they should be kept safe and stranspoted safe.
  • Logging is needed but we should also set up a 24/7 monitoring system that monitors our logs, infrastructure and API endpoints. We should get an alert from this system if a breach occurs.
  • Security Information and Event Management (SIEM) systems can be used to aggregate logs from all components of the API technology stack and the virtual hosts.
  • The catch an attacker earlier, set up custom dashboards and alerting fit for your environment.
  • Implement API security solution

Conclusion

Insufficient Logging & Monitoring may not seem to be impactful at first but like with any issue type, if we look under the hood there is much more to be found. If there is not sufficient logging an attacker can roam freely and take their time and even if there was enough logging, that is no guarantee that there will also be monitoring to watch those logs. Given the severity of this type and what it can do though, it would not be wise to ignore logging and monitoring until the last minute and to bake it into the designs of the software that's created. Read our OWASP Top 10 2021 research paper, which compares vulnerabilities for 2021.

Watch the video:

FAQ

References

Subscribe for the latest news

Updated:
March 5, 2024
Learning Objectives
Subscribe for
the latest news
subscribe
Related Topics