0

Seeking any example of exploitable unsafe deserialiazation where the serialized format is json and not some binary format.

Even better would be an example where calling a Java constructor of an arbitrary class(in some common library) is sufficient to do something malicious, and not rely on vulnerable readResolve, readObject or such specific to Java Serialization.

Improve this question
4
  • 2
    I googled your title and got this as the top hit: owasp.org/images/d/d7/…
    – schroeder ♦
    Jun 11, 2019 at 9:19
  • Any specific reason you mention Java? JSON deserialization libraries are available for all major languages, and languages like C (with no variable-length string type) are naturally more vulnerable.
    – MSalters
    Jun 11, 2019 at 9:31
  • 1
    This is embarrassing, I obviously googled a bit, but only when writing the question did a formalize better what I was looking for, mostly I wanted to refute claim that the issue is only with binary formats like Java serialization and python pickles. At a glance the link answers at least my first part, but using setters and not using non default constructors as in my second part.
    – Meir Maor
    Jun 11, 2019 at 9:33
  • Is not clear what you asking for, looks like a programing question more than security question
    – camp0
    Jun 11, 2019 at 10:38

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .