Skip main navigation


Watch Paulo Silva explain how to prevent insufficient logging and monitoring. This video will revise application vulnerabilities.
Welcome to the third and last part of Insufficient Logging and Monitoring session. In this part, we will discuss mitigation. We will start discussing what makes an application vulnerable and then we will handle OWASP Juice Shop vulnerable source code. Before closing this session, we will discuss how to avoid such vulnerabilities. When auditible events, such as logins, either successful or failed attempts, and high value transactions are not logged or log messages do not include enough details, applications are at risk. If logs are stored locally only or they are not monitored for suspicious activity, then they won’t help organizations to detect and mitigate security incidents on a timely fashion.
If alerting thresholds are not well adjusted or response escalation processes are not in place or effective, then malicious activity may still pass unnoticed. The same is valid if all this fails under attack due to high traffic or load. Already discussed security misconfigurations may make logs and alerting events available to regular users and attackers, leaving the application vulnerable. Let’s now have a look at the source code. From project page, we will jump straight to the GitHub repo.
We are looking for the server.js script, where we should find the login root setup.
The login function is implemented in the root/login.js file. Let’s jump to the implementation.
This is a server side source code responsible to perform the log-in.
First we have a database query to bring the matching record.
This source code branch corresponds to a successful log in. The afterLogin function is called. Let’s check its implementation.
All its logic is focused on finding or creating a new user shopping basket, nothing related to the login.
Back to the login function, failed login attempts are handled in this source code branch. Again, no logging– just a 401 HTTP response status code is returned. In case of exception, the next express framework handler is called. Let’s get back to the main server.js file and check how the error handling is setup.
Errors are handled by the error handler function provided by the node.js package with the same name.
According to the package documentation, it is only intended to be used in development. But this is the only error handling Juice Shop uses.
Still, according to the documentation, full error stack traces and internal details of any object passed to this module will be sent back to the client. This makes sense, since we didn’t see any error log files during the exploitation part, and in several other sessions, we have got errors client-side including such information. Either successful and failed login attempts should be logged, as well as input validation failures. Such logs should include sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis. Choose standard formats for logging, enabling logs to be consumed by a centralized log management solution.
High value transactions should have an audit trail with integrity controls to prevent tampering and deletion and append only database table or similar may be enough. But nowadays, it can take advantage of other technologies, such as blockchain. Adopting a security incident and event management solution will certainly help implementing effective monitoring and alerting. A dedicated team in the proper incident response and recovery plan will get your organization in a better shape to handle security incidents appropriately. This was the last session of OWASP Top 10 Security Fundamentals course. I hope you have enjoyed our journey through the top 10 most common web application security risks. You can continue practising on OWASP Juice Shop shop. There are several other vulnerabilities to find.
Remember to check OWASP’s website at and join your local chapter. Cheers.

In this final video of the course, you will learn how to prevent insufficient logging and monitoring.

System logging and monitoring are important for all kinds of attacks. In this video, you will briefly revise what makes an application vulnerable. You will then learn how to strengthen your system to prevent these vulnerabilities and avoid insufficient logging and monitoring.

Users are reminded of what to look for to identify whether their application is vulnerable. The video then shows users what to look for in the application scripts and explains what they can do to protect their system.

Investigate and share: The first video of this section included a table from the OWASP Insufficient Logging and Monitoring page. Review the table and the additional information provided and share what you find most useful.

Prepare for Test of the Week

You have completed the content for this week! You are now ready to move on to the Test of the Week.

The following test is going to assess your understanding of what you have learned within this past week of the course.

Remember, you do not have to take the test until you’re ready. To help you prepare, you might wish to spend some time refreshing your understanding of the contents of the past week.

You may wish to reflect on the Learning Outcomes introduced at the beginning of the week and make sure you are comfortable that you have met the requirements of each. Take some time to review your learning to help you prepare.

This article is from the free online

Advanced Cyber Security Training: OWASP Top 10 and Web Application Fundamentals

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now