DevSkim/guidance/DS425000.md

## Do not deserialize untrusted data

### Summary

Many deserialization implementations suffer from a common security flaw - an
attacker able to influence the payload being deserialized may be able to
execute arbitrary code.

### Details

You can mitigate the risk of deserialization vulnerabilities in a few different
ways, described below.

##### Add integrity protection to the payload

Most serialization implementations don't include any integrity protection,
but you can add this yourself. This can be done by using a digital
signature, an HMAC, or an authenticated encryption scheme. Of course, the
integrity would need to be checked prior to deserializing the payload.

This would prevent deserialization vulnerabilities because an attacker won't
be able to update the payload without the integrity check failing.

##### Don't allow an attacker to handle the payload

If only trusted users handle the payload, then there's very little risk.
However, you should fully consider your threat model before deciding that
an attacker would never be able to supply a tampered payload. Consider
things like network traffic, file system ACLs, direct memory access, 
virtualization, swap files, etc. before making this decision.

##### Don't allow unsafe objects to be deserialized

You can partially mitigate this risk by specifying an "allowed" list of
classes when deserializing an object -- any object type specified in the 
payload but not in the "allowed" list would result in a failure.

This requires support within the deserialization routine.

##### Don't allow any objects to be deserialized

This certainly wouldn't work in all cases, but if you're only expecting
data, then using a simple data format (JSON or XML) with only basic types
should fully mitigate this risk.


#### Programming Languages

##### Python - pickle / cPickle

The Python `pickle` and `cPickle` modules can be exploited by an
attacker-created serialized object to run arbitrary code.

You can use these modules safely only if one of the following is true:

* The serialized object is never under the control of an untrusted party.
* You add integrity protection to the serialized object (such as an HMAC
  or a digital signature) and verify it before deserializing it. 

###### References

* [Why Python Pickle is Insecure](https://michael-rushanan.blogspot.de/2012/10/why-python-pickle-is-insecure.html)
* [Understanding Python Pickling and How to Use it Securely](https://www.synopsys.com/blogs/software-security/python-pickling/)
* [Python 3 Docs - Pickle](https://docs.python.org/3/library/pickle.html)


##### Java

The `readObject` function is dangerous as an attacker-supplied payload would
execute arbitrary code.

###### References

* [https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/](https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)

### Severity Considerations

The severity of this finding should be increased if user-supplied content is
passed to the deserialization routing, but depends very much on the overall
context.

### References

* [https://www.owasp.org/index.php/Deserialization_Cheat_Sheet](https://www.owasp.org/index.php/Deserialization_Cheat_Sheet)