Open pixeebot[bot] opened 1 month ago
I'm confident in this change, and the CI checks pass, too!
If you see any reason not to merge this, or you have suggestions for improvements, please let me know!
Just a friendly ping to remind you about this change. If there are concerns about it, we'd love to hear about them!
This change may not be a priority right now, so I'll close it. If there was something I could have done better, please let me know!
You can also customize me to make sure I'm working with you in the way you want.
This change may not be a priority right now, so I'll close it. If there was something I could have done better, please let me know!
You can also customize me to make sure I'm working with you in the way you want.
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code
@pixeebot next
@nahsra, I don't have any suggestions at this time, but I am always learning, and I will let you know if anything comes up!
Remediation
This change fixes "Untrusted Deserialization" (id = untrusted-deserialization) identified by Contrast Assess.
Details
This change fixes Java deserialization vulnerabilities. Even a simple operation like an object deserialization is an opportunity to yield control of your system to an attacker. In fact, without specific, non-default protections, any object deserialization call can lead to arbitrary code execution. The JavaDoc now even says:
Let's discuss the attack. In Java, types can customize how they should be deserialized by specifying a
readObject()
method like this real example from an old version of Spring:Reflecting on this code reveals a terrifying conclusion. If an attacker presents this object to be deserialized by your app, the runtime will take a class and a method name from the attacker and then call them. Note that an attacker can provide any serliazed type -- it doesn't have to be the one you're expecting, and it will still deserialize.
Attackers can repurpose the logic of selected types within the Java classpath (called "gadgets") and chain them together to achieve arbitrary remote code execution. There are a limited number of publicly known gadgets that can be used for attack, and our change simply inserts an ObjectInputFilter into the
ObjectInputStream
to prevent them from being used.This is a tough vulnerability class to understand, but it is deadly serious. It offers the highest impact possible (remote code execution), it's a common vulnerability (it's in the OWASP Top 10), and exploitation is easy enough that automated exploitation is possible. It's best to remove deserialization entirely, but our protections is effective against all known exploitation strategies.
More reading
* [https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html) * [https://portswigger.net/web-security/deserialization/exploiting](https://portswigger.net/web-security/deserialization/exploiting)🧚🤖 Powered by Pixeebot
Feedback | Community | Docs | Codemod ID: contrast:java/java-deserialization