OWASP API #10: Insufficient Logging & Monitoring

Santiago Rosenblatt
strike.sh
Published in
4 min readMar 31, 2021

This section

As a reminder, we started with this section more than two months ago đŸ™ŒđŸ» . Our main purpose, is to share once a week, one of the top cybersecurity attacks that applications are suffering nowadays and help by explaining how you can prevent them from happening.

It is insane that with the 10th OWASP related article, we have been publishing for more than 10 weeks in a row and just wanted to thank all of you who are reading this and have read the past ones. To all of you, thank you very much!

In each story, we go through ‘Brief explanation’, ‘Is my API vulnerable?’, ‘Attack scenarios’ and ‘How to prevent?’, so by the end you have a comprehensive understanding.

If you missed the previous articles, we encourage you to go have a look. We have already covered:

API #10: Insufficient Logging & Monitoring

If you are close to the development and infrastructure environment, you might be familiar with the amount of events that occur and are triggered on a daily basis for your applications.

That amount of valuable information is the one that allows you to properly audit your systems and get notified when something is wrong, a service is not working or you are being hacked.

When you are monitoring and there is an event, if you are not logging, then it is pretty much impossible to determine up to what extent your applications have been damage, how much information an attacker was able to retrieve, how valuable the assets were and so on.

This all sums up into telling that logging and monitoring is the last of this series, but one of the most important for sure, so you definitely need to make an emphasis in this.

Brief explanation

Insufficient Logging & Monitoring refers to an application that is not producing enough logs and monitoring information to properly and thoroughly audit your systems.

Is my API vulnerable?

Your application is vulnerable when:

  • It does not produce any logs, the logging level is not set correctly, or log messages do not include enough detail.
  • Log integrity is not guaranteed (e.g., Log Injection).
  • Logs are not continuously monitored.
  • API infrastructure is not continuously monitored.

Example attack scenario

The access keys of an administrative API were leaked on a public repository.

The repository owner was notified by email about the potential leak, but took more than 48 hours to act upon the incident. The access keys had an administrator role so an attacker with them, was able to do anything inside the AWS infrastructure, including setting up EC2 instances to mine cryptos or access sensitive information stored in S3 buckets.

Due to insufficient logging, the company is not able to assess what data was accessed by malicious actors.

How to prevent?

  • Log all failed authentication attempts, denied access, and input validation errors.
  • Logs should be written using a format suited to be consumed by a log management solution, and should include enough detail to identify the malicious actor.
  • Logs should be handled as sensitive data, and their integrity should be guaranteed at rest and transit.
  • Configure a monitoring system to continuously monitor the infrastructure, network, and the API functioning.
  • Configure custom dashboards and alerts, enabling suspicious activities to be detected and responded to earlier.

Conclusion

As mentioned in the beginning, logging and monitoring is without any doubts a fundamental part of securing your applications.

Without monitoring, there is no way to know whether you are actually being attack and when. It’s tough but the truth is that if you are not seeing any abnormal behavior (at least in your external endpoints) you might be lacking monitoring as today there are scans everywhere looking for exposed devices since the first minute they are launched.

In addition to monitoring, logging helps you trace the root causes when problems arise and be certain about what happened, who accessed what and which information could have been compromised.

Taking into account all of this, and wrapping up: be aware of the importance of placing proper and clear logs in your systems, and specially in the critical functions, that would definitely help you have a better sense of how secure you are.

As a side not, I just wanted to thank all of you that have been reading and sharing comments, questions and recommendations with us. We are going to be posting some more OWASP API related posts and then start getting deep into vulnerabilities such as XSS, SSRF, CRFS and SQLi so we can all learn and get protected together.

Thank you for taking the time and reading this week’s story on OWASP API TOP 10. As usual, if you have any doubts or need any help, anyone at Strike will be happy to help you. You can reach out to me here or in LinkedIn!

If you want to see daily news, tips and funny memes (yes, we are into that too :D), be sure to give us a follow there too.

Cheers from Strike :)

--

--

Santiago Rosenblatt
strike.sh
Editor for

Founder & CEO at Strike.sh | Ethical Hacker | Computer Engineer | Go Getter âœŒđŸ» - “Embrace reality and deal with it” https://linkedin.com/in/santiagorosenblatt