Mitigation

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.