Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more


In this video, watch Paulo Silva explain how to spot and rectify errors in the system protocols that leave it vulnerable to deserialization attacks.
Welcome back to the third and the last part of Insecure Deserialization session. In this part, we will discuss insecure deserialization mitigation. We’ll 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. Whenever an application deserializes data supplied by external entities, such as users or third-party systems, then it is at risk. Note that user-supplied data includes HTTP request errors, cookies, query string parameters, request body data, metadata extracted from uploaded content, et cetera. The same way, data gathered from external systems pose a security risk. Malicious actors may go after such systems instead of directly targeting your application.
Let’s have a look at the source code. From Juice Shop project page, we will jump to the GitHub Repo.
We are looking for the server.js file, where we should find the Swagger setup as well as the B2B orders API routes.
This is the Swagger UI setup.
And this is the B2B API routes, handled by the B2B order function, implemented in the B2B order.js file in the routes folder. Let’s jump straight to the implementation.
We can see here that orderLinesData is retrieved from the request body.
Then it is passed to the safeEval function, which runs inside the sandbox.
Due to the timeout option, the denial of service was not possible using the infinite loop.
Let’s discuss how to avoid insecure deserialization.
Always avoid accepting serialized objects from untrusted sources. If you cannot avoid it, limit serialisation and deserialization to primitive data types only. Implement integrity checks, such as digital signatures, on any serialized objects to prevent hostile data object creation or data tampering. Performing deserialization on a sandbox or a low privilege environment helps lowering the impact of insecure deserialization flaws. Restrict network in such environments. Log deserialization exceptions and failures, especially those related to unexpected data types. Monitor deserialization, alerting whenever suspicious activity is detected, such as when a user deserializes frequently. In our next session, we will discuss using components with known vulnerabilities. Until then, take your time to carefully read the Insecure Deserialization section of our OWASP top 10.

In this video, you will learn how to identify and rectify errors in the system protocols that leave it vulnerable to deserialization attacks.

Now that you understand how deserialization works and how hackers can take advantage of it, you will learn how to increase your system’s protection against these attacks.

This video shows how the protocols of a system can leave it open to deserialization attacks, and how to mitigate these threats. You will go through a demonstration of what to assess in the code, and how to adapt the code.

Investigate and share: Go to the OWASP Insecure Deserialization page to find the table mentioned in the first video of this section and read more about insecure deserialization. Share what you learn here!

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