4 ms·

Defense in depth is a thing. Trusting the message queue to be the only security barrier into your system is not great. Wouldn't be the first time one of those

• stickfigure 2y ago
  Each defense intervention needs to be weighed against its cost, and also against the threat model. If the attacker can inject arbitrary content into the message queues of most business applications, they already have the keys to the castle. And all of those other serialization libraries come with costs and tradeoffs. I'm guessing you work in security and don't actually build production systems for a living?
  • lucumo 2y ago
    > Each defense intervention needs to be weighed against its cost, What cost? Jackson for example is just as easy - if not easier - than Java serialization. It's widely used (therefore well tested), actively maintained and well-designed. > If the attacker can inject arbitrary content into the message queues of most business applications, they already have the keys to the castle. They can make your application follow different steps of the application's own rules. Java serialization is one badly designed class on the classpath away from an RCE: in which case it can completely ignore your application's rules. For example, if you have a compromised message queue for creating users, a good serialization lib won't stop the attacker from creating an admin user, but it will stop the attacker from dumping your user database and TLS private key. Java serialization will not stop that at all. That's not hypothetical, BTW. About a decade ago a whole bunch of exploits came out that used Java's serialization and popular libraries on the classpath. Many resulting in remote code execution. That's why you can now set an ObjectInputFilter or `jdk.serialFilter`. But those don't save anybody when they're not set. And they are not set by default. > I'm guessing you work in security and don't actually build production systems for a living? You guessed wrong. I've built many production systems and am still building production systems. Look, I've frequently been annoyed by the same thing you're accusing me of: overzealously trying to reduce risks to the point of ridiculous expense. But that's not what this is. There is very little benefit to using Java serialization, and it adds weaknesses that are unnecessary. When building something new, using a different solution significantly hardens your system at essentially no extra costs. It can be more costly to retrofit existing systems. That's a situation where the filters can be useful. The whole code then becomes the type of code nobody wants to have, but that we all have too much of anyway. We call it legacy and strive to have less of it next time.
    • stickfigure 2y ago
      I'm just going to quote myself from the thread above: > You can serialize object graphs without concern for cycles. The contract is simple (it serializes fields, as opposed to dealing with weird bean naming conventions). It handles types and structures automatically. `transient` is built into the language. Polymorphism just works. I like Jackson more than most. And there are many contexts in which JSON is the better answer. But there are also many contexts in which Java serialization is a better answer. Even with the security considerations.