1

I'm reading up on Insecure Deserialization and remembered a vulnerability that I read about in some JSON Web Token (JWT) implementations at auth0.

https://owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

Long story short the "none" algorithm is used, signature is removed and the application believes whatever the user sends is OK. Would this fall under Insecure Deserialization or Using Components with Known Vulnerabilities? The given example could of course be Broken Access Control but given that the user controls the object they could manipulate the system in other ways as well.

https://owasp.org/index.php/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities

{"alg":"HS256","typ":"JWT"}.{ "admin": false, "name": "John Doe", "iat": 1516239022}.signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhZG1pbiI6ZmFsc2UsIm5hbWUiOiJKb2huIERvZSIsImlhdCI6MTUxNjIzOTAyMn0.lN5mCX6BnfgtoRVHVaTt9hcj3VUcHWAwdnTT-PLca3c

{"alg":"none","typ":"JWT"}.{ "admin": true, "name": "John Doe", "iat": 1516239022}.signature

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJhZG1pbiI6dHJ1ZSwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

The examples that I find are from PHP, Python and Java and some descriptions indicates that JSON or XML is not a part of the classification.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process. Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control, and remote code execution attacks.

OWASP Deserialization Cheat Sheet

Yes the vulnerability is more important than the classification but I'm still interested in correct classifications.

2

Tldr: Clear distinction between vulnerabitily classes ist not always possible.


To look at "insecure serialization" in a different way first:
From the description, Owasps "insecure serialization" is a bit of a foggy mix of (imo) 3 separate problems:

  • A specific subsection of plain untrusted input values for the very first - who cares about serialization formats. In your code block, the admin:true (and the server believing this value) is the problem, nothing else. If it stands alone, outside of any Json etc., it's still the same problem.
  • Still untrusted input, but another section: Exchanging code (classes, methods...). If there is some dependency injection going on for a EncryptionAlgorithmInterface, and the available implementations are None, DES, AES256 and so on - what could I do with the serialized object? Changing the algorithm to none and then find a place where I can read the data while send over the internet.
  • Problems by definition in the serializer itself. What if send a never-ending stream of [[[[[[[[[[[[[[[... to a web service expecting Json (ie. Array of array of array of... and the values and closing ] are never sent)? A simple implementation will quickly reach a stack overflow (error, not website), crashing the server process.

Your Json web token link...

  • is at least untrusted input.
  • It also is (Owasps) insecure serialization, but really, who cares - the problem again is not the data format.
  • After the explanation was written, it also became "running components with known vulnerabilities".
  • Not in Owasps Top10, but it is also a protocol definition problem.
  • ...

Finally, about the part of native serialization that offers more than Json etc.: Well, partially - but this doesn't make eg. PHPs version secure.

In Java it is possible to take an object, write it's complete state to an byte array (that is, current member variable content (both simple types as well as other objects), but also executable binary code in some situations, etc.) and then recreate everything from this byte array. Access to a serialized Java method that will be executed later is of course very nice for doing bad things. And if there is none, introducing one that will be called because of its name at some point (eg. equals) is easy too.

In PHP, there is not such a straightforward way to save and load executable code parts like the runtime has them in memory, so abusing this is not possible. However, names of other methods to call might still be in there. That's not as convenient, but still nice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.