Insecure Deserialization

Date: March 21, 2023

Insecure Deserialization

Introduction
The process of serialization involves flattening complex data structures, like objects and their fields, so they may be delivered and received as a stream of bytes. It is significantly less complicated to:

• Write complicated data to a database, a file, or inter-process memory.
• Convey complex data, for instance, via a network, among application components, or through an API call.
• Importantly, when an object is serialized, its state is also preserved. In other words, the properties of the object are retained, along with the values that were assigned to them.

Deserialization is the process of turning this byte stream back into an identical clone of the original object that is fully operational and maintains its serialized state. The logic of the website can then communicate with this deserialized object in the same way that it would with any other object. Serialization is natively supported by several programming languages. Depending on the language, objects are serialized in various ways. While some languages serialize data into multiple string formats with variable degrees of human readability, others serialize them into binary formats. Keep in mind that the serialized data stream contains all of the original object's attributes, including any private fields. A field must be explicitly designated as "transient" in the class declaration in order to prevent serialization.

What does unsafe deserialization entail?
When a website deserializes data that can be modified by the user, it is doing so insecurely. By manipulating serialized objects, an attacker may be able to send malicious data into the application code. Even an object of a different class can be used to replace a serialized object. Uncomfortably, regardless of which class was anticipated, objects of any class that is available to the website will be deserialized and instantiated. Because of this, unsafe deserialization is occasionally referred to as an "object injection" vulnerability. An exception might be brought about by an object of an unexpected class. But by then, perhaps the damage is already done. Many deserialization-based assaults are finished prior to the end of deserialization. This means that even if the website's own functionality does not directly interact with the malicious item, the deserialization process itself may start an attack. Because of this, websites with strongly typed language-based logic may potentially be susceptible to similar tactics.

How do unsecured deserialization flaws develop?
The most common reason of unsafe deserialization is a general ignorance of the risks associated with deserializing user-controllable data. User input ought to never be deserialized in the ideal world. Because they offer some sort of extra check to the deserialized data, website owners occasionally believe they are secure. Because it is practically hard to create validation or sanitization to account for every possibility, this technique frequently fails. These checks also have a basic weakness in that they verify the data after deserialization, which is frequently too late to stop the attack. Deserialized objects are frequently taken for granted as being reliable, which can lead to vulnerabilities. Developers may believe that consumers can't successfully read or manipulate the data, particularly when employing languages with a binary serialization format. Although it might take more work, an attacker can still use string-based formats as well as binary serialized items to their advantage. Due to the large number of dependencies present in contemporary websites, deserialization-based attacks are also made possible. A normal website might use a variety of libraries, each of which has its own set of dependencies. This generates a sizable pool of classes and methods that is challenging to securely manage. It is difficult to foresee which methods can be used on the bad data because an attacker can construct instances of any of these types. This is particularly true if an attacker is able to chain together a number of unexpected methods calls and deliver data to a sink that is unrelated to the original source. Hence, it is virtually impossible to foresee the flow of dangerous data and close every possible gap.

Effects of insecure deserialization
Applications and APIs will be vulnerable, according to OWASP, if they deserialize hostile or modified objects provided by an attacker. Two main sorts of attacks may emerge from this:

• Assaults on objects and data structures that alter application logic or permit uncontrolled remote code execution if the programme has access to classes that can alter behavior before, during, or after deserialization.

• Access-control-related attacks, which utilize existing data structures but change the content, are examples of common data tampering attacks.

Applications that use serialization include:
• RPC/IPC refers to remote and inter-process communication.
• Web services, message brokers, and wire protocols
• Databases, cache servers, file systems, and persistence
• HTML form fields, HTTP cookies, and API authentication tokens

The programming language, serialization formats, and software libraries used all have a big impact on how serialization and deserialization work. Thankfully, there isn't a "one-size-fits-all" strategy for tackling an unsafe deserialization flaw. Although this makes the vulnerability more difficult to identify and exploit, it in no way lessens its danger.
How to stop vulnerable deserialization issues
In general, user input should not be deserialized until it is absolutely essential. If you must deserialize data from unreliable sources, take strong precautions to ensure that the data has not been altered. You could, for instance, use a digital signature to verify the accuracy of the data. However, keep in mind that any necessary tests must be performed before starting the deserialization procedure. They are not very useful if not. You should try to stay away from using any general deserialization features. All of the characteristics of the original object, including secret fields that can contain sensitive information, are included in the serialized data from these methods. Instead, you may develop your own class-specific serialization techniques to at least have some degree of control over the accessible fields.

Finally, keep in mind that the vulnerability is not the existence of gadget chains that subsequently handle the data, but rather the deserialization of user input. Avoid relying solely on trying to break down device chains that you find during testing. Due to the web of cross-library dependencies that very probably exists on your website, it is impracticable to attempt to plug them all. Moreover, publicly disclosed memory corruption attacks may exist at any time, which means that your programme



Insecure deserialization is notoriously challenging to exploit. But there are occasions when it's lot easier than you may imagine. This problem frequently requires manual work, therefore automated attacks are less likely to take advantage of it. An exploit, however, can be automatically constructed once for one system and then used against all other computers that are running the same apps. Depending on how the serialized item is used, the effect may vary. Given the circumstances, remote command or remote code execution, which would be regarded as the most serious, is definitely a possibility.

Conclusion
Web applications that routinely serialize and deserialize data experience insecure deserialization. Deserializing data from unreliable sources could now result in remote code execution. Insecure deserialization issues can give an attacker remote programme execution right, the ability to alter or remove serialized (written to disc) objects, the ability to conduct injection attacks, and more. In general, user input should not be deserialized until it is absolutely essential. Due to the possible high severity of exploits it could enable and the difficulties in preventing them, the negatives frequently outweigh the benefits. If you must deserialize data from unreliable sources, take strong precautions to ensure that the data has not been altered. You could, for instance, use a digital signature to verify the accuracy of the data. However, keep in mind that any necessary tests must be performed before starting the deserialization procedure.