WEBVTT

00:00:00.000 --> 00:00:06.640 align:middle line:90%


00:00:06.640 --> 00:00:08.380 align:middle line:84%
Welcome to the
third and last part

00:00:08.380 --> 00:00:10.990 align:middle line:84%
of Broken
Authentication session.

00:00:10.990 --> 00:00:13.750 align:middle line:84%
In this part, we will
discuss authentication flaws

00:00:13.750 --> 00:00:15.370 align:middle line:90%
mitigation.

00:00:15.370 --> 00:00:17.050 align:middle line:84%
We will start
discussing what makes

00:00:17.050 --> 00:00:19.360 align:middle line:84%
an application
vulnerable, and then we

00:00:19.360 --> 00:00:22.600 align:middle line:84%
will hunt OWASP Juice Shop
vulnerable source code.

00:00:22.600 --> 00:00:26.610 align:middle line:84%
Then we will discuss how to
avoid such vulnerabilities.

00:00:26.610 --> 00:00:29.250 align:middle line:84%
If your application does not
enforce a strong password

00:00:29.250 --> 00:00:33.390 align:middle line:84%
policy, like OWASP Juice
Shop, then it is vulnerable.

00:00:33.390 --> 00:00:36.970 align:middle line:84%
Showing a password
strength bar is not enough.

00:00:36.970 --> 00:00:39.390 align:middle line:84%
If an application does
nothing to detect and stop

00:00:39.390 --> 00:00:42.090 align:middle line:84%
automated attacks,
then sooner or later,

00:00:42.090 --> 00:00:43.870 align:middle line:90%
accounts will be compromised.

00:00:43.870 --> 00:00:45.510 align:middle line:84%
You have seen how
easy it is to get

00:00:45.510 --> 00:00:48.150 align:middle line:84%
the username/password
combination lists.

00:00:48.150 --> 00:00:51.710 align:middle line:84%
OWASP Juice Shop users a
security question within

00:00:51.710 --> 00:00:55.320 align:middle line:84%
to exploit it, but we could have
done so the same way we brute

00:00:55.320 --> 00:00:56.610 align:middle line:90%
forced the password.

00:00:56.610 --> 00:00:59.730 align:middle line:84%
Download the common English
female first names list

00:00:59.730 --> 00:01:01.950 align:middle line:84%
and keep sending requests
to the application

00:01:01.950 --> 00:01:04.690 align:middle line:84%
until we get the
positive response.

00:01:04.690 --> 00:01:07.500 align:middle line:84%
This is the worst password
recovery challenge

00:01:07.500 --> 00:01:08.460 align:middle line:90%
you can use--

00:01:08.460 --> 00:01:10.580 align:middle line:90%
you cannot fix it.

00:01:10.580 --> 00:01:13.460 align:middle line:84%
An ineffective
multifactor authentication

00:01:13.460 --> 00:01:15.620 align:middle line:90%
is as bad as not having one.

00:01:15.620 --> 00:01:18.560 align:middle line:84%
Sometimes, multifactor is
required in the front end,

00:01:18.560 --> 00:01:21.170 align:middle line:84%
but not validated
by the back end.

00:01:21.170 --> 00:01:24.650 align:middle line:84%
Session management is another
common authentication issue.

00:01:24.650 --> 00:01:27.890 align:middle line:84%
We didn't exploit it, but you'll
find extensive documentation

00:01:27.890 --> 00:01:28.820 align:middle line:90%
about the topic--

00:01:28.820 --> 00:01:30.620 align:middle line:90%
search and read it.

00:01:30.620 --> 00:01:33.240 align:middle line:84%
Let's have a look
at the source code.

00:01:33.240 --> 00:01:35.250 align:middle line:84%
From OWASP Juice
Shop project page,

00:01:35.250 --> 00:01:37.380 align:middle line:84%
we can jump directly
to the GitHub repo.

00:01:37.380 --> 00:01:44.530 align:middle line:90%


00:01:44.530 --> 00:01:46.420 align:middle line:84%
Juice Shop server
is bootstrapped

00:01:46.420 --> 00:01:48.340 align:middle line:90%
into server.js file.

00:01:48.340 --> 00:01:55.980 align:middle line:90%


00:01:55.980 --> 00:01:58.410 align:middle line:84%
Unlike other routes,
the signup one

00:01:58.410 --> 00:02:01.680 align:middle line:84%
is automatically generated
by npm package called Finale.

00:02:01.680 --> 00:02:09.750 align:middle line:90%


00:02:09.750 --> 00:02:12.060 align:middle line:84%
Following this approach,
signup request data

00:02:12.060 --> 00:02:14.430 align:middle line:84%
is passed directly
to the user model.

00:02:14.430 --> 00:02:16.963 align:middle line:84%
Well, it doesn't sound
like a good idea.

00:02:16.963 --> 00:02:18.630 align:middle line:84%
We need to have a
look at the user model

00:02:18.630 --> 00:02:20.670 align:middle line:84%
to understand how to
sign up really works.

00:02:20.670 --> 00:02:53.130 align:middle line:90%


00:02:53.130 --> 00:02:55.290 align:middle line:84%
The user model
has just a schema,

00:02:55.290 --> 00:02:58.140 align:middle line:84%
meaning that signup request
data is saved directly

00:02:58.140 --> 00:02:59.670 align:middle line:90%
into the database.

00:02:59.670 --> 00:03:02.340 align:middle line:84%
Not only is the password
strength not enforced,

00:03:02.340 --> 00:03:07.350 align:middle line:84%
but the confirmation password
matching is also missing.

00:03:07.350 --> 00:03:09.710 align:middle line:84%
Let's now have a look at
the security dash question

00:03:09.710 --> 00:03:12.350 align:middle line:84%
endpoint used to enumerate
Juice Shop accounts.

00:03:12.350 --> 00:03:41.450 align:middle line:90%


00:03:41.450 --> 00:03:44.000 align:middle line:84%
This is the function responsible
to retrieve the security

00:03:44.000 --> 00:03:45.380 align:middle line:90%
question from the database.

00:03:45.380 --> 00:03:48.750 align:middle line:90%


00:03:48.750 --> 00:03:52.590 align:middle line:84%
Given an email address, it
looks up in the database

00:03:52.590 --> 00:03:55.710 align:middle line:90%
to find the user records.

00:03:55.710 --> 00:03:59.970 align:middle line:84%
If a record was found, then
it searched the database

00:03:59.970 --> 00:04:04.410 align:middle line:84%
for the security
question records.

00:04:04.410 --> 00:04:06.330 align:middle line:84%
If a security
question was found,

00:04:06.330 --> 00:04:09.000 align:middle line:90%
then it is returned as JSON.

00:04:09.000 --> 00:04:14.210 align:middle line:84%
Otherwise, an empty
JSON object is returned.

00:04:14.210 --> 00:04:17.390 align:middle line:84%
This is what creates the binary
feedback allowing attackers

00:04:17.390 --> 00:04:19.610 align:middle line:84%
to use the application
as in Oracle to enumerate

00:04:19.610 --> 00:04:21.529 align:middle line:90%
user accounts.

00:04:21.529 --> 00:04:23.480 align:middle line:84%
Let's now have a look
at the login root.

00:04:23.480 --> 00:04:41.280 align:middle line:90%


00:04:41.280 --> 00:04:46.710 align:middle line:84%
We have seen dysfunction before
in our injection flow session.

00:04:46.710 --> 00:04:49.620 align:middle line:84%
We know that this SQL query
is responsible to match

00:04:49.620 --> 00:04:52.770 align:middle line:84%
provided email and password
against database records.

00:04:52.770 --> 00:05:09.000 align:middle line:90%


00:05:09.000 --> 00:05:12.510 align:middle line:84%
If no record matching the
email and password is found,

00:05:12.510 --> 00:05:16.080 align:middle line:84%
then we jump straight
to this ELSE clause,

00:05:16.080 --> 00:05:18.600 align:middle line:84%
and here, we just
return an error code

00:05:18.600 --> 00:05:21.690 align:middle line:84%
and the invalid email
or password message.

00:05:21.690 --> 00:05:24.660 align:middle line:84%
There's no failed login
attempt counter being

00:05:24.660 --> 00:05:27.270 align:middle line:90%
updated or special logging.

00:05:27.270 --> 00:05:29.610 align:middle line:84%
The lack of lockout
feature, rate limiting,

00:05:29.610 --> 00:05:31.560 align:middle line:84%
and insufficient
logging, makes it

00:05:31.560 --> 00:05:33.120 align:middle line:84%
possible to
perpetrate brute force

00:05:33.120 --> 00:05:34.860 align:middle line:84%
attacks such as the
credential stuffing

00:05:34.860 --> 00:05:37.860 align:middle line:84%
one we did to find the admin
passwords without being

00:05:37.860 --> 00:05:40.120 align:middle line:90%
noticed.

00:05:40.120 --> 00:05:42.160 align:middle line:84%
If you're building
a new application,

00:05:42.160 --> 00:05:44.290 align:middle line:84%
then consider multifactor
authentication

00:05:44.290 --> 00:05:46.690 align:middle line:84%
since it will be
easy to implement.

00:05:46.690 --> 00:05:49.930 align:middle line:84%
Otherwise, if you're maintaining
an existing application,

00:05:49.930 --> 00:05:51.580 align:middle line:84%
changing your current
implementation

00:05:51.580 --> 00:05:54.160 align:middle line:90%
is worth every second.

00:05:54.160 --> 00:05:56.800 align:middle line:84%
Probably, you won't be
able to get rid of password

00:05:56.800 --> 00:05:58.810 align:middle line:90%
as authentication factor.

00:05:58.810 --> 00:06:01.000 align:middle line:84%
Enforce strong
passwords and test them

00:06:01.000 --> 00:06:04.240 align:middle line:90%
against common or leaked ones.

00:06:04.240 --> 00:06:06.070 align:middle line:84%
Do not deploy or
ship your application

00:06:06.070 --> 00:06:07.420 align:middle line:90%
with default passwords.

00:06:07.420 --> 00:06:09.460 align:middle line:84%
Otherwise, they will
become shared secrets,

00:06:09.460 --> 00:06:13.300 align:middle line:84%
and hey, while shared,
it is no more a secret.

00:06:13.300 --> 00:06:15.130 align:middle line:84%
Make sure none of
the authentication

00:06:15.130 --> 00:06:18.130 align:middle line:84%
mechanisms leak information
about whether an account exists

00:06:18.130 --> 00:06:18.910 align:middle line:90%
or not.

00:06:18.910 --> 00:06:21.130 align:middle line:84%
The recover password
mechanisms tend

00:06:21.130 --> 00:06:23.620 align:middle line:84%
to be a good candidate
for account enumeration.

00:06:23.620 --> 00:06:25.480 align:middle line:84%
Make sure the response
feedback remains

00:06:25.480 --> 00:06:29.560 align:middle line:84%
the same regardless whether
the account exists or not.

00:06:29.560 --> 00:06:31.330 align:middle line:90%
Log failed login attempts.

00:06:31.330 --> 00:06:34.780 align:middle line:84%
After a few, lock the account
and notified the owner.

00:06:34.780 --> 00:06:36.940 align:middle line:84%
Application owner
should also be notified

00:06:36.940 --> 00:06:40.450 align:middle line:84%
that application or a single
account is under attack.

00:06:40.450 --> 00:06:43.150 align:middle line:84%
Sessions should be
managed server side.

00:06:43.150 --> 00:06:45.490 align:middle line:84%
Choose a well documented
and actively maintained

00:06:45.490 --> 00:06:47.440 align:middle line:90%
session management library.

00:06:47.440 --> 00:06:52.060 align:middle line:84%
Audit the library specifically
regarding tokens lifecycle.

00:06:52.060 --> 00:06:54.790 align:middle line:84%
In our next session, we
will discuss sensitive data

00:06:54.790 --> 00:06:55.840 align:middle line:90%
exposure.

00:06:55.840 --> 00:06:58.300 align:middle line:84%
Until then, take your
time to carefully read

00:06:58.300 --> 00:07:02.250 align:middle line:84%
the Broken Authentications
section of OWASP Top 10.

00:07:02.250 --> 00:07:03.000 align:middle line:90%