sreeramadasugiri (Community Member) asked a question.
Hi Team,
In my java code, i am getting vulnerability in DAST flaw like 502 Deserialization of Untrusted Data with Vulnerable Parameter: @class and
Original Value: com.core.vo.AddressVo. And,
Description
A signature of a serialized object has been found in the request to https://his21-3sit.com:9426/company-name-web/HISServices/HITService. The serialization format used appears to contain type information, that is used on the server side to construct an object of an arbitrary type. There is a high chance that this type is not on an allowlist, so a potential attacker is able to create an instance of any class existing in the target classpath and call its methods with arbitrary values. These methods include a default contructor, getters, setters or special "magic" methods, such as "readObject" or "readExternal". Since a common Java application contains thousands of classes from JDK and libraries, it is often possible to use known combination of classes (called "gadget chains") to achieve remote code execution on the target server. Identified serialization technology: unknown
Can anyone help me to fix the DAST flaws.
Regards,
Giri
.png){kind=logo}
Hi @sreeramadasugiri (Community Member),
Veracode Dynamic Analysis reports CWE 502 when it can observe a string that looks like a serialized object in an HTTP request to your backend. As an example for Java, our dynamic engine would report CWE 502 when it detects a string that starts with `rO0` being sent around. This is because this string would indicate a serialized and base64 encoded Java object, which is very likely going to be base64 decoded and deserialized again in the backend. Deserializing potentially untrusted data is very dangerous and can lead to DoS, bypassing access control, or even Remote Code Execution (RCE) where an attacker takes over the entire server. To achieve this, an attacker would serialize a malicious Java object using tools like `ysoserial` (https://github.com/frohoff/ysoserial). Upon deserialization, the malicious code would then be executed.
The general recommendation would be to avoid (de-)serializing Java objects altogether and, instead, use a safer serialization format such as JSON or Protobuf. If this is not possible, the only mitigation I would feel comfortable with is using signatures. In a nutshell: Whenever your backend serializes a Java object, it creates a digital signature for it which is sent along with the serialized object. Upon deserialization, the backend first checks the signature and makes sure that the object-to-deserialize has not been tampered with and is actually an object that has been serialized by a trusted entity (and not an attacker).
There are also some other potential mitigating controls such as allow-listing what types may be deserialized in your backend. However, these mitigating controls are difficult to implement and error-prone. Moreover, implementing them incorrectly may make your application vulnerable to the most devastating attacks again (RCE).
I would recommend that you schedule a consultation to further discuss this with a member of our Application Security Consulting team. The following article describes how to schedule a consultation: https://community.veracode.com/s/article/How-to-schedule-a-consultation-call.
Thank you,
Florian Walter