WEBVTT

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


00:00:06.120 --> 00:00:08.850 align:middle line:84%
Welcome back to the third
and the last part of Insecure

00:00:08.850 --> 00:00:10.800 align:middle line:90%
Deserialization session.

00:00:10.800 --> 00:00:14.040 align:middle line:84%
In this part, we will discuss
insecure deserialization

00:00:14.040 --> 00:00:15.750 align:middle line:90%
mitigation.

00:00:15.750 --> 00:00:17.160 align:middle line:84%
We'll start
discussing what makes

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

00:00:19.050 --> 00:00:22.410 align:middle line:84%
will handle OWASP Juice
Shop vulnerable source code.

00:00:22.410 --> 00:00:25.260 align:middle line:84%
Before closing this
session, we will discuss how

00:00:25.260 --> 00:00:27.980 align:middle line:90%
to avoid such vulnerabilities.

00:00:27.980 --> 00:00:30.320 align:middle line:84%
Whenever an application
deserializes

00:00:30.320 --> 00:00:32.460 align:middle line:84%
data supplied by
external entities,

00:00:32.460 --> 00:00:37.370 align:middle line:84%
such as users or third-party
systems, then it is at risk.

00:00:37.370 --> 00:00:41.480 align:middle line:84%
Note that user-supplied data
includes HTTP request errors,

00:00:41.480 --> 00:00:44.780 align:middle line:84%
cookies, query string
parameters, request body data,

00:00:44.780 --> 00:00:49.230 align:middle line:84%
metadata extracted from
uploaded content, et cetera.

00:00:49.230 --> 00:00:52.230 align:middle line:84%
The same way, data gathered
from external systems

00:00:52.230 --> 00:00:54.180 align:middle line:90%
pose a security risk.

00:00:54.180 --> 00:00:56.910 align:middle line:84%
Malicious actors may
go after such systems

00:00:56.910 --> 00:00:59.970 align:middle line:84%
instead of directly
targeting your application.

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

00:01:02.750 --> 00:01:06.170 align:middle line:84%
From Juice Shop project page,
we will jump to the GitHub Repo.

00:01:06.170 --> 00:01:13.670 align:middle line:90%


00:01:13.670 --> 00:01:16.580 align:middle line:84%
We are looking for the
server.js file, where

00:01:16.580 --> 00:01:20.190 align:middle line:84%
we should find the Swagger setup
as well as the B2B orders API

00:01:20.190 --> 00:01:20.690 align:middle line:90%
routes.

00:01:20.690 --> 00:01:36.960 align:middle line:90%


00:01:36.960 --> 00:01:38.730 align:middle line:90%
This is the Swagger UI setup.

00:01:38.730 --> 00:01:47.540 align:middle line:90%


00:01:47.540 --> 00:01:51.260 align:middle line:84%
And this is the B2B API routes,
handled by the B2B order

00:01:51.260 --> 00:01:55.460 align:middle line:84%
function, implemented in the
B2B order.js file in the routes

00:01:55.460 --> 00:01:56.300 align:middle line:90%
folder.

00:01:56.300 --> 00:01:58.677 align:middle line:84%
Let's jump straight
to the implementation.

00:01:58.677 --> 00:02:16.700 align:middle line:90%


00:02:16.700 --> 00:02:20.015 align:middle line:84%
We can see here that
orderLinesData is retrieved

00:02:20.015 --> 00:02:21.440 align:middle line:90%
from the request body.

00:02:21.440 --> 00:02:25.470 align:middle line:90%


00:02:25.470 --> 00:02:28.490 align:middle line:84%
Then it is passed to
the safeEval function,

00:02:28.490 --> 00:02:30.335 align:middle line:90%
which runs inside the sandbox.

00:02:30.335 --> 00:02:38.620 align:middle line:90%


00:02:38.620 --> 00:02:41.230 align:middle line:84%
Due to the timeout option,
the denial of service

00:02:41.230 --> 00:02:43.480 align:middle line:84%
was not possible using
the infinite loop.

00:02:43.480 --> 00:02:46.384 align:middle line:90%


00:02:46.384 --> 00:02:49.750 align:middle line:84%
Let's discuss how to avoid
insecure deserialization.

00:02:49.750 --> 00:02:52.410 align:middle line:90%


00:02:52.410 --> 00:02:54.960 align:middle line:84%
Always avoid accepting
serialized objects

00:02:54.960 --> 00:02:57.030 align:middle line:90%
from untrusted sources.

00:02:57.030 --> 00:02:59.700 align:middle line:84%
If you cannot avoid
it, limit serialisation

00:02:59.700 --> 00:03:04.150 align:middle line:84%
and deserialization to
primitive data types only.

00:03:04.150 --> 00:03:07.450 align:middle line:84%
Implement integrity checks,
such as digital signatures,

00:03:07.450 --> 00:03:10.480 align:middle line:84%
on any serialized objects
to prevent hostile data

00:03:10.480 --> 00:03:13.690 align:middle line:84%
object creation
or data tampering.

00:03:13.690 --> 00:03:16.810 align:middle line:84%
Performing deserialization on
a sandbox or a low privilege

00:03:16.810 --> 00:03:19.270 align:middle line:84%
environment helps
lowering the impact

00:03:19.270 --> 00:03:22.030 align:middle line:84%
of insecure
deserialization flaws.

00:03:22.030 --> 00:03:25.510 align:middle line:84%
Restrict network in
such environments.

00:03:25.510 --> 00:03:28.660 align:middle line:84%
Log deserialization exceptions
and failures, especially

00:03:28.660 --> 00:03:32.060 align:middle line:84%
those related to
unexpected data types.

00:03:32.060 --> 00:03:34.580 align:middle line:84%
Monitor deserialization,
alerting whenever

00:03:34.580 --> 00:03:37.430 align:middle line:84%
suspicious activity is
detected, such as when

00:03:37.430 --> 00:03:40.460 align:middle line:90%
a user deserializes frequently.

00:03:40.460 --> 00:03:43.640 align:middle line:84%
In our next session, we will
discuss using components

00:03:43.640 --> 00:03:45.150 align:middle line:90%
with known vulnerabilities.

00:03:45.150 --> 00:03:47.750 align:middle line:84%
Until then, take your
time to carefully read

00:03:47.750 --> 00:03:52.500 align:middle line:84%
the Insecure Deserialization
section of our OWASP top 10.

00:03:52.500 --> 00:03:53.000 align:middle line:90%