14 lines
1.7 KiB
Plaintext
14 lines
1.7 KiB
Plaintext
== Why is this an issue?
|
|
|
|
:link-with-uscores1: https://docs.microsoft.com/en-us/dotnet/api/system.codedom.compiler.tempfilecollection.-ctor?view=netframework-4.8#System_CodeDom_Compiler_TempFileCollection__ctor
|
|
|
|
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 ``{link-with-uscores1}[TempFileCollection]`` with arbitrary files (defined by an 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 is called). This kind of types are called "https://github.com/pwntester/ysoserial.net[gadgets]".
|
|
|
|
|
|
Instead of using ``++BinaryFormatter++`` and similar serializers, it is recommended to use safer alternatives in most of the cases, such as https://docs.microsoft.com/en-us/dotnet/api/system.xml.serialization.xmlserializer?view=net-5.0[XmlSerializer] or https://docs.microsoft.com/en-us/dotnet/api/system.runtime.serialization.datacontractserializer?view=net-5.0[DataContractSerializer]. If it's not possible then try to mitigate the risk by restricting the types allowed to be deserialized:
|
|
|
|
* by implementing an "allow-list" of types, but keep in mind that novel dangerous types are regularly discovered and this protection could be insufficient over time.
|
|
* or/and implementing a 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. |