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 ask just shop, vulnerable source
code, before closing, this session. We will discuss how
to avoid such vulnerabilities when auditable
events, such as login, either successful or
failed attempts. And high-value transactions are not locked
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.
Stations to detect and mitigate security incidents on
a timely fashion. If allergen thresholds are
not, well, adjusted or response, Collision process are
not in place or effective. Then militias 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.
Okay.
From projects page, we will jump straight to the GitHub repo.
We are looking for the server.js script where
we should find a log in route setup.
The login function is implemented in the road /. Login
dot J's file. Let's jump to the implementation.
This is a server-side source code responsible to
perform the login.
First, we have a database query to bring the matching records.
This source code Branch corresponds to a successful login.
The after login 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, tax code has returned.
In case of exception, the next Express framework, Handler
is called. Let's get back to the main
server. Dot J's file, and check how they are handling is
set up.
Errors are handled by the air 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, Lahore 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 her log
files, during the exploitation part, and in several other
sessions. We have got a horse client-side including such
information.
Either successful in 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 help 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 an
append-only database table, or similar may
be an F. But nowadays, you 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.
Apparently, I hope you have enjoyed our
journey through the top 10, most common web application security,
risks. You can continue practicing on
all hospitals shop. There are several other vulnerabilities to
find, remember to check our apps website that
allows plot Arc and join your local chapter. Cheers.