The thing you let in (deserialization and file uploads)

The two doors every app has: where the outside world’s data comes in, and where its own data goes back out. This lesson is the first door at its worst: not a text field, but a whole object or a whole file, handed over by someone you have never met.

Before you start. Application Hardening said to check what knocks, in one line that included “a file upload”. Web Vulnerabilities (the OWASP classics) showed what happens when an attacker’s text becomes a database query or a page. Review the fix (secure code review) had you review handlers that took a path or a field they should not have. This lesson is about two inputs that look like data and behave like instructions: a saved object that is rebuilt on arrival, and a file the user named and filled.

The idea in 30 seconds

Deserialization rebuilds objects from bytes, and in formats like Python’s pickle and Java’s built-in serialization, rebuilding can run code the sender chose.
The 2015 “Marshalling Pickles” attack made one common Java library run commands for a stranger, and the same chain worked against WebLogic, WebSphere, JBoss, Jenkins and OpenNMS.
Bytes that cross a trust boundary are read with a format that can only describe data, such as JSON, and then checked against an allowlist of expected keys, types and ranges.
An upload’s name and Content-Type header are claims by the client; the file’s first bytes are the evidence of what it is.
Store an upload under a name you generated, accept only an allowlist of kinds (not SVG for an avatar), cap its size first, and keep it where the web server does not run it.

Read the story · Skip to the numbers