Welcome to the third and last part of broken authentication
session. In this part. We
will discuss authentication false mitigation. We
will start discussing what makes an application vulnerable. And
then we will hunt all us Juice Shop, foldable
source code. Then we will discuss how
to avoid such vulnerabilities.
If your application does not enforce a strong password policy
like Alaska to shop, then it
is vulnerable showing a password. Strength bar
is not enough. If application does nothing
to detect and stop automated attacks. Then
sooner or later accounts will be compromised. You have
seen how easy it is to get the username password combination list.
I'll ask Juice Shop uses a security question.
We didn't exploit it, but we
could have done. So the same way we Brute Force the password.
Download the common English female first names list
and keep sending requests to the application until
we get the positive response. This is
the worst password recovery challenge. You can use.
You cannot fix it.
And ineffective multi-factor authentication is
as bad as not having one. Sometimes, multi-factor
is required in the front end, but not validated
by the back end. Session management is
another common authentication issue. We didn't
exploit, but you'll find extensive documentation about
the topic search and read it. Let's have
a look at the source code from. Oh, ask Juice
Shop project page. We can jump directly to the GitHub repo.
Joyce shop server is bootstrapped in the server.js file.
Unlike other routes, the sign-up one is automatically generated
by npm package called finale.
Following this approach. Sign up, request data is
passed directly to the user model. What doesn't sound
like a good idea. We need to have a look at the
user model to understand how the sign up really works.
The other model has just the schema meaning that signup
request data is saved directly into the database. Not
only the password strength is not enforced, but
the confirmation password matching is also missing.
Let's now have a look at the security Dash questioning Point
used to enumerate Juice Shop accounts.
This is the function responsible to retrieve the security question
from the database.
Given an email address. It
look up the database to find the user records.
If a record was found, then
it search the database for the security question
records.
If a security question was found then it is returned
as Jason. Otherwise an
empty. Json object is returned.
This is what creates the binary feedback allowing attackers
to use the application as an oracle to enumerate user accounts.
Let's now have a look at the log in route.
We have seen this function before on our injection flaws
session.
We know that the sequel query is responsible to
match provided email and password against database
records.
If no record matching, the email and password is found. Then
we jump straight to this else
clause in here. We just return an error
code and invalid email or password message. There
is no failed, login attempt, counter being
updated or special logging the
lack of lockout feature rate limiting and insufficient logging
makes it possible to perpetrate brute-force attacks,
such as the credential stuffing when we did to find the
admin passwords without being noticed.
If you're building a new application, then consider multi-factor
authentication, since it will be easy to implement. Otherwise,
if you're maintaining an existing application
changing your current implementation worth every
second. Probably you won't
be able to get rid of password as authentication factor in
for strong passwords and test them against common or
licked ones.
Do not deploy your ship, your application with default passwords. Otherwise,
they will become shared secrets. And hey,
once shared it is no more, a secret. Make
sure none of the authentication mechanisms. Leaked
information about whether an account exists or not, the
recover password mechanisms tend to be a good candidate for
account enumeration. Make sure the response feedback Remains
the Same regardless, whether the account exists or
not, log failed, login attempts, after
a few lock the account in notified.
The Wallner application Wonder should also be notified that
application or a single account is under attack session.
Should be managed server site choose
a well-documented and actively maintained session management Library.
I'll did the library specifically regarding
tokens life cycle.
In our next session, we will discuss sensitive data, exposure until
then, take your time to carefully read the broker. Authentication section
of a wasp top 10.