4 ms·

To make it able to be serialized?... Am I missing something?

by Timwi 2y ago

evidencetamper 2y ago
You don't need your optional to be serialized - it's just a container. You need what's inside your optional to be serialized.
crummy 2y ago
Most of the serialization libraries I use (Jackson, gson) ignore the Serialization interface. I think it's only used for Java's now-rarely-used native serialization functionality.
lucumo 2y ago
Only Java's built-in serialization still requires Serializable. And Java's built-in serialization is fundamentally vulnerable and should never be used. Newer libraries dropped the need for Serializable, because whether or not an object is serializable is not just dependent on its class, but also on the features the serialization library supports.
- stickfigure 2y ago
  > Java's built-in serialization is fundamentally vulnerable and should never be used If you added "...for public APIs" then I would agree. But that represents only a tiny portion of the use cases for serializing objects. Java serialization excels at many of them.
  - lucumo 2y ago
    If you have FULL control over the serializing code and the serialized file during the entire time between serialization and deserialization, it can be safe. Put the file on the filesystem with incorrect permissions, transfer it over unencrypted HTTP, or do any number of things that allow others to mess with your data and you're screwed. Don't use it. It relies on the unsafe data to tell it what class to unmarshall to. If any class on your classpath does anything weird in its deserializing code, you've lost. Nowadays it's possible to filter the classes that can get deserialized, but: 1) there's still way too much Java 8 code around that doesn't have that filter; 2) those were the same JDK-wide until Java 17; and 3) worst of all, nobody uses them. Using Java serialization is like playing the knife game. You can win. But you'd better not make even a tiny mistake.
    - stickfigure 2y ago
      This is dumb. If you're using it for internal RPC, or putting it in a message queue, or putting it in memcache, etc etc then you control both sides. A huge amount of business processing works like this. It's totally fine. Not every protocol needs to be designed for the REST use case. We have REST (and gRPC, and thrift, and avro, and many other protocols) for that. Use the correct tools for the job and stop the FUD.
      - lucumo 2y ago
        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 gets misconfigured. When that happens, using Java serialization leaves your system open in a way that other serialization libraries just don't.
        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.

To make it able to be serialized?... Am I missing something?

by Timwi 2y ago

To make it able to be serialized?... Am I missing something?

You don't need your optional to be serialized - it's just a container. You need what's inside your optional to be serialized.

crummy 2y ago

Most of the serialization libraries I use (Jackson, gson) ignore the Serialization interface. I think it's only used for Java's now-rarely-used native serialization functionality.

lucumo 2y ago

Only Java's built-in serialization still requires Serializable. And Java's built-in serialization is fundamentally vulnerable and should never be used. Newer libraries dropped the need for Serializable, because whether or not an object is serializable is not just dependent on its class, but also on the features the serialization library supports.

stickfigure 2y ago
> Java's built-in serialization is fundamentally vulnerable and should never be used If you added "...for public APIs" then I would agree. But that represents only a tiny portion of the use cases for serializing objects. Java serialization excels at many of them.
- lucumo 2y ago
  If you have FULL control over the serializing code and the serialized file during the entire time between serialization and deserialization, it can be safe. Put the file on the filesystem with incorrect permissions, transfer it over unencrypted HTTP, or do any number of things that allow others to mess with your data and you're screwed. Don't use it. It relies on the unsafe data to tell it what class to unmarshall to. If any class on your classpath does anything weird in its deserializing code, you've lost. Nowadays it's possible to filter the classes that can get deserialized, but: 1) there's still way too much Java 8 code around that doesn't have that filter; 2) those were the same JDK-wide until Java 17; and 3) worst of all, nobody uses them. Using Java serialization is like playing the knife game. You can win. But you'd better not make even a tiny mistake.
  - stickfigure 2y ago
    This is dumb. If you're using it for internal RPC, or putting it in a message queue, or putting it in memcache, etc etc then you control both sides. A huge amount of business processing works like this. It's totally fine. Not every protocol needs to be designed for the REST use case. We have REST (and gRPC, and thrift, and avro, and many other protocols) for that. Use the correct tools for the job and stop the FUD.
    - lucumo 2y ago
      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 gets misconfigured. When that happens, using Java serialization leaves your system open in a way that other serialization libraries just don't.
      - 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.