Failure to control types during deserialization can lead to runtime errors and vulnerabilities. There are many types, called "gadgets" which are known to be dangerous when deserializing. All languages are affected and the most in-depth studies have been carried out for:
* PHP: https://github.com/ambionics/phpggc[phpgcc] - _library of unserialize() payloads_.
* Java: https://github.com/frohoff/ysoserial[ysoserial] - _A tool for generating payloads that exploit unsafe Java object deserialization_.
* .NET: https://github.com/pwntester/ysoserial.net[ysoserial.net] - _Deserialization payload generator for a variety of .NET formatters_.
During the deserialization process, the state of an object will be reconstructed from the serialized data stream which can contain dangerous operations.
For example, a well-known attack vector consists in serializing an object of type ``++https://javadoc.idrsolutions.com/org/jpedal/io/ObjectStore.html[org.jpedal.io.ObjectStore]++`` in Java, ``++https://docs.microsoft.com/en-us/dotnet/api/system.codedom.compiler.tempfilecollection.-ctor?view=netframework-4.8#System_CodeDom_Compiler_TempFileCollection__ctor[TempFileCollection]++`` in C# and ``++https://framework.zend.com/apidoc/1.12/classes/Zend_Http_Response_Stream.html[Zend_Http_Response_Stream]++`` in PHP, with arbitrary files defined by the attacker which will be deleted on the application deserializing this object (when the https://docs.microsoft.com/en-us/dotnet/api/system.codedom.compiler.tempfilecollection.finalize?view=netframework-4.8[finalize() ]method of the TempFileCollection object, for instance, is called).
* implement a whitelist of safe and required types that can be deserialized.
* or/and implement tamper protection, such as https://en.wikipedia.org/wiki/HMAC[message authentication codes] (MAC), this way only objects serialized with the correct MAC hash will be deserialized.
