Serialization is a technique that can transform an object into a byte stream. In the Java programming language, these objects are used to perform a variety of tasks, including authentication and a variety of other tasks. The objects are transformed into a byte stream and then assigned to the user as a cookie, which aids in the authentication process and helps the user identify themselves. Deserialization is the opposite of serialization in that the byte stream returned by the users, which is essential in the HTTP request, is captured by the server and then changed into objects in order to validate the permission sessions of the user, and so forth.
Because of this, Java Deserialization is a mechanism that turns a byte stream into an object, however, the deserialization process causes a large number of security vulnerabilities. Consequently, let us have a discussion about these.
What is Deserialization Vulnerability of Untrusted Data in Java Applications?
If the deserialization of the byte streams is performed in an unsafe manner, it can result in a large number of vulnerabilities. They have the potential to lead to authentication bypass as well as RCE.
If applications accept data without performing any sanitization or processing it without performing any validation, this can result in a serious vulnerability. It is known as “Deserialization” to convert byte streams into network objects or data objects from multiple formats, such as JSON or XML. Deserialization makes the program’s structure more vulnerable, and developers can import serialization objects into any custom application as a result of this procedure. Because of this, there will be no need to add or create new columns on every change as a result.
Consider the following example: When a user registers into an application, the program assigns this cookie to the user in order to keep track of his current state on the server, according to the application.
Tzo0OuKAnVVzZXLigJ06Mjp7czo4OuKAnXVzZXJuYW1l4oCdO3M6NDrigJ10ZXN04oCdO3M6NTrigJ1hZG1pbuKAnTtiOjA7fQ==
Given that this cookie is base64 encoded, we can expect to receive a set of objects of this type after decoding the cookie, as seen below.
O:4:”User”:2:{s:8:”username”;s:4:”test”;s:5:”admin”;b:0;}
You can easily see that here permission is being defined, “s” means that the characters are of string and “b” means boolean so if you set b:1 from b:0 you can have access to the admin panel. So this can be used to perform the authentication bypass on the application.
Why does it occur?
Attackers can take advantage of this functionality and manipulate the serialized data because there is no validation performed before the data is processed by the application, which may result in unsafe Deserialization. Untrusted data can readily exploit the weak deserialization function and carry out serious attacks such as access control bypass, the execution of undesired operations, RCE, and many other types of attacks on the target system.
If this state conversion does not make use of any constructors, it will result in the creation of an empty object. As a result, “Constructor level verification and validation” was not performed during the object’s creation in this instance.
Look at a few code snippets that demonstrate how java deserialization is implemented. Serializable classes in Java are responsible for implementing the readObject and writeObject methods, respectively:
According to the code snippet above, a file is being produced using the object “Hi,” and this object is currently being serialized, which will result in the creation of a file that will be delivered to the user.
The content of the file can now be modified by the user using any of the hex decoders available. This code is used to deserialize a file that has been transmitted to the server from the user’s computer.
So, in general, because the program is accepting altered or modified files, it will be simple to exploit the deserialization vulnerability in the application.
How to Remediate
We are all familiar with the Java deserialization vulnerability and how it might manifest itself, however this vulnerability manifests itself when there is no validation performed when converting the byte stream from the objects to bytes. As a result, in order to mitigate this vulnerability, avoid using serialization of objects whenever possible. As a result, if you want to implement serialization in your application, you must first check the ObjectInputStream before performing the deserialization operation. An example of a library that can be of assistance is the Apache Commons I/O library.
This library offers a ValidatedObjectInputStream, which allows you to explicitly enable the deserialization of the objects you want to use in your program. You’ve now eliminated the potential of unanticipated types of deserialization from occurring.
This vulnerability frequently emerges as a result of the inputs being utilized directly to acquire or retrieve files from a server. This is commonly performed by implementing input validation into the user input and whitelisting all of the files that can be obtained using the fetching parameter in the code.
How I Used WhiteSource Cure to Remediate
These problems are generally caused by developers failing to adhere to fundamental best practices when publishing code, such as not checking user inputs before utilizing them. Therefore, an automated vulnerability scanner is required to scan code for vulnerabilities before merging it in order to identify and correct any issues that may arise.
A buddy of mine who previously used WhiteSource Cure for Java cleanup recommended it to me. According to them, they are “the world’s first custom code security auto-remediation program.” Security considerations don’t have to slow down the speed with which you produce code and applications any longer when utilizing this tool, as I discovered when conducting research for this article.
It scans the GitHub repository for security flaws. In a DevOps workflow, it reads code to see if anything needs to be changed. For this project, I used a free tool that you can use for as long as you like. It also generates a report with remedial alternatives for the flaws that have been identified.
If you apply those patch proposals, you’ll immediately fix the problem, just like if you’d written the fix code yourself. There’s also an IDE plugin included, so applying the patch is as easy as clicking a button! It’s a big help.
How to Use WhiteSource Cure
Using WhiteSource Cure is very easy. I am using the well-known vulnerability app from OWASP, WebGoat, for this demonstration.
- Go to GitHub and copy the repo link of WebGoat.
- Go to this link, and it will show you a page like this:
- Enter the repo link in the first input field and leave the second field blank and click Fix It!
- After that, it will open a page that has all the vulnerabilities detected in your repository.
Click on any vulnerability, and it will show you where that vulnerability occurs.
- If you want to look for a fix, click on the remediation tab, and it will show you the code required to fix that issue.
Conclusion
Without addressing deserialization vulnerabilities, the organization is at risk of being very vulnerable. Because of this, scanning your code before deployment is critical in ensuring that it can be patched if necessary. If you want to undertake a code review and application patching, you can utilize an automated code scanner like whitesource cure.
