schandra868249 (Community Member) asked a question.

how to fix 502  Deserialization of Untrusted Data

The veracode is complaining for the below code

timeKeyMillis = aInputStream.readLong();

timeKeyNano = aInputStream.readLong();

methodName = (String)aInputStream.readObject();

symbol = (String)aInputStream.readObject();

text = (String)aInputStream.readObject();

fields = (HashMap<String, RTFieldData>)aInputStream.readObject();

fields_num = (HashMap<Integer, String>)aInputStream.readObject();

productData = (ArrayList<String>)aInputStream.readObject();

 

Here only where readObject() method is used only there Veracode points the flaw. But for the other lines like readLong() it doesn't .

We also tried to subclass the ObjectInputStream class and override the resolveClass() method but did not help.

Kindly help us in resolving this flaw.


  • Seb! (Veracode)

    Hello @schandra868249!

     

    Only readObject() will flag as a flaw because it’s the only method that doesn’t applying any assertions to the binary stream it’s reading. This makes it an attack vector as malicious payloads can be read fully.

     

    readLong() knows it’s dealing with Long data types. As such it will only read 8 bytes from the binary stream and will return the correct type – or throw an IOException if anything disrupts that.

     

    With this vulnerability, we would first recommend removing the use of readObject() if possible. As noted with readLong(), there are number of safe method such as readString() which make assertions on the binary stream. If it’s possible to refactor to only use the safe methods, you will remove this flaw completely and it will not show in your Veracode results.

     

    If readObject() is necessary, then yes overriding readObject() to provide your own safe implementation is another approach. I would recommend reading this article for advice on how to do that safely https://www.contrastsecurity.com/security-influencers/protect-your-apps-from-java-serialization-vulnerability. The approach in this article is similar to how readLong() is implemented, with stream reading length restrictions. Another approach would be to use a library such as https://github.com/ikkisoft/SerialKiller which provides a look-ahead mechanism before deserialization.

     

    Either technique can be used, but if you choose to take these approach you will need to enter a mitigation such as “Mitigation by Design” and detail the steps taken.

    Expand Post

Topics (1)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.