Our great sponsors
-
ysoserial
A proof-of-concept tool for generating payloads that exploit unsafe Java object deserialization.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I'd say, take a look at error handling. In Haskell you can accomplish a lot by just using `Maybe` and `Either` along with the functions related to them, provided by the standard library. Haskell's pattern matching feature makes it even more straight forward to handle these types.
A lot of this translates to Rust, as Haskell influenced the language design of Rust. In Rust you have `std::option::Option` and `std::result::Result` which relate closely to `Maybe` and `Either`, respectively. Also pattern matching is available in Rust.
When you then look at other (imperative) languages like Go, C, and C++, error handling becomes a bit more cumbersome IMHO. I am not talking about explicit or implicit error handling. It's more about urging the programming to check for and handle errors, and also giving them the necessary tools to do that efficiently.
In Go, you have lots of `if err != nil { return err }`, which is cumbersome to write (luckily we have snippets) and _clutters_ the code. Yes, it is explicit and easy to read, but I don't think error handling should make up 4/5 of the lines of your algorithm.
The same applies to C, more or less, as functions typically tell you about success or failure via their return value. Like `err` in Go.
In C++ we have `std::optional` which is handy, but C++ lacks a lot of functional features and convenient syntax to take full advantage of it. No straight forward pattern matching here. There is `std::variant` to create sum types, but I've only seen that in use occasionally. There is also `std::expected` on the horizon, which is similar to `Either` / `std::result::Result`, but adoption will take ages.
C++, being a complicated language, makes it very difficult to just come up with your own wrapper classes that _just work_. See https://github.com/oktal/result/blob/master/result.h for example.
> A similar issue has occurred with Java (and other languages, see https://frohoff.github.io/appseccali-marshalling-pickles/). Java provided a suberbly user-friendly way of serializing any object to disk and recovering it back in its original form. The only unfortunate problem was that there was no way to say which object you are expecting! This allows attackers to send you objects that, upon deserialization in your program, become nasties that wreak havoc and steal data.
Not correct. You can certainly inspect before instantiation:
https://docs.oracle.com/javase/7/docs/platform/serialization...