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.
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 everything, not just the logs but make sure you monitor the APIs and the infrastructure as well.
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.
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.
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).
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.
Subscribe for the latest news