Preventing insecure deserialization NET PHP isn’t about avoiding it. Modern apps have to move complex data. You ensure safety. Treat every byte as hostile. Enforce strict rules. Reject client-controlled data. This is a mindset shift, not just a library.
Our specific patterns fix a common flaw. This flaw allows remote code execution. We replace it with a predictable, safe data flow. Keep reading to see how Secure Coding Practices builds this in from the start.
Secure Deserialization Essentials
Preventing insecure deserialization NET PHP starts with a few core practices that work together. They reduce deserialization risks and make remote code execution attacks much harder.
- Never let the client dictate the object type. Enforce a strict allowlist of permitted classes.
- Use safer, data-only formats. Replace dangerous serializers like PHP’s
unserialize(). Also replace .NET’sBinaryFormatter. - Layer your defenses. Cryptographically sign data for integrity. But do not rely on signing alone. It cannot validate object types.
What Makes a Serialized Object a Weapon?
The flaw is one of misplaced trust. Deserialization rebuilds an object using a blueprint. Insecure deserialization occurs. Your app accepts a user’s blueprint. It follows this blueprint without question. That’s what an insecure deserialization vulnerability really means.
Attackers exploit this. They manipulate the blueprint. This misuses code already in your app’s memory.
- In NET, they often use the
$typeproperty. This tells the serializer, “instantiate this specific class.” They point it to a “gadget”, a harmless-seeming class with a dangerous constructor or setter. - In PHP, the
unserialize()function automatically calls magic methods like__wakeup(). Attackers craft “POP chains,” linking these calls to achieve remote code execution.
Research from RWTH Aachen University shows
“In the Java deserialization vulnerability, the gadget chain is the method call chain from the deserialization entry method
readObject()to the command execution methodexec().” – RWTH Aachen University
The result is catastrophic. Remote code execution gives attackers a foothold. They can access your server directly. This leads to data theft. It can also result in a full system takeover. The dangers of insecure deserialization extend far beyond application crashes. We drill this risk CWE-502 into every student at our bootcamp.
Which NET Serializers Should You Retire Now?
Preventing insecure deserialization NET PHP requires retiring unsafe NET serializers immediately whenever they process untrusted data. They’re unsafe for external data.
BinaryFormatter, NetDataContractSerializer, and LosFormatter are the main culprits. Their design lets the incoming data specify any object type to create. Microsoft has marked BinaryFormatter obsolete because of this. There’s no safe way to use them on untrusted input.
In a recent analysis by Microsoft.com
“
BinaryFormatteris considered unsafe because it’s vulnerable to deserialization attacks, which can lead to denial of service (DoS), information disclosure, or remote code execution. It was implemented before deserialization vulnerabilities were well understood, and its design doesn’t follow modern security best practices.” – Microsoft.com
| Serializer | External Data | Recommendation |
| BinaryFormatter | Unsafe | Replace immediately |
| NetDataContractSerializer | Unsafe | Avoid |
| System.Text.Json | Safer | Preferred choice |
For modern .NET, use System.Text.Json. It forces you to specify the target type, like Deserialize<MyClass>(json), which blocks most attacks.
If you’re using Json.NET, check the TypeNameHandling setting. It must be set to None. Any other value lets the payload dictate types, reopening the vulnerability.
How Do You Build a Safe Deserialization Pipeline in NET?
Choosing a safe serializer is only the first step. You then need to enforce a strict contract. Your code must know exactly what data it’s allowed to receive.
Start by validating the raw input. Check its length and basic structure. Is it even valid JSON? This simple filter can stop obvious attacks early.
The critical rule is controlling which types can be created. If you truly need polymorphism, implement a strict allowlist.
With System.Text.Json, you use a custom JsonTypeInfoResolver. This acts as your gatekeeper. It compares the requested type against a hardcoded list of permitted classes. Anything else gets rejected.
var options = new JsonSerializerOptions
{
TypeInfoResolver = new DefaultJsonTypeInfoResolver
{
Modifiers = { RestrictToAllowedTypes }
}
};
static void RestrictToAllowedTypes(JsonTypeInfo typeInfo)
{
if (typeInfo.Type != typeof(AllowedClassA) &&
typeInfo.Type != typeof(AllowedClassB) &&
typeInfo.Type != typeof(AllowedClassC))
{
throw new UnauthorizedAccessException(
$"Deserialization of type {typeInfo.Type} is not permitted."
);
}
}For client-side data like cookies, add a cryptographic signature with an HMAC. Crucially, verify the signature before you deserialize. If it’s invalid, reject the payload outright. Never deserialize first and verify later.
Why Is PHP’s unserialize() a Built-in Security Hazard?
PHP’s unserialize() is dangerous because of its “magic methods.” When an object is revived, PHP automatically calls __wakeup(). When it’s destroyed, it calls __destruct(). Attackers create a serialized string. This string manipulates class properties. They chain these automatic calls. This executes their code. This is a PHP Object Injection attack.
The best prevention is to avoid unserialize() for any external data. Use json_decode() instead. JSON handles data like arrays and strings. It cannot recreate arbitrary PHP objects with methods.
// The Hazardous Way
$userObject = unserialize($_COOKIE['user_session']); // Triggers __wakeup()
// The Secure Way
$userData = json_decode($_COOKIE['user_session'], true); // Returns an array
$user = new User();
$user->setId($userData['id']);
$user->setName($userData['name']);If you’re stuck with legacy code using unserialize(), use the allowed_classes parameter. This lets you specify an exact allowlist of classes, or pass false to allow none.
// Only these specific classes can be instantiated
$data = unserialize($input, ['allowed_classes' => ['MySafeDTO']]);
// No classes can be instantiated
$data = unserialize($input, ['allowed_classes' => false]);Setting allowed_classes to false is a good defense. However, it does not stop attacks. These attacks can come from deeply nested arrays.You must still validate the input’s structure and size first.
What Security Defenses Work Across All Programming Languages?
Several core security principles apply to any language.
Validate all input early. Check data length, structure, and format at the API boundary before it reaches the deserializer.
Run the process with the least privilege possible. If an attacker gets through, they shouldn’t have administrator access.
Monitor and log deserialization failures. A sudden spike in errors can signal an attack. Log context, but not the full malicious payload.
Integrate these checks into your workflow. Add dangerous patterns to code reviews. Use static analysis tools to flag unsafe code like BinaryFormatter. Scan dependencies for vulnerable libraries. During threat modeling, always identify where data is deserialized and question its source.
How Do You Put Secure Deserialization Into Practice?
Credit: Bishow Pandey
Moving from theory to practice is messy.
For .NET, find and replace every BinaryFormatter. It’s often buried in old caching code. You might need an intermediate step like protocol buffers before a full rewrite to System.Text.Json.
For PHP, hunt down every unserialize(). Replace it with json_decode() where possible. If you can’t, wrap it with allowed_classes => false. Many attack examples start with legacy deserialization code that remains in production. It’s a grind, but it works.
A common error is trusting cryptography alone. Encrypting a payload doesn’t make it safe to deserialize. You must verify the signature on the raw data before you begin the deserialization process. Signatures protect data, not object graphs. You need both steps.
FAQs
How does insecure deserialization PHP prevention reduce application risk?
Insecure deserialization in PHP can be prevented. This reduces risk. You can validate input. Only accept data from trusted sources. Verify signed serialized data. Block object injection. These practices reduce the deserialization attack surface and help prevent remote code execution.
Why is the PHP allowed_classes option important when processing unserialized user input?
The PHP allowed_classes option limits which classes can be instantiated during unserialize operations. This helps whitelist classes. It blocks unexpected objects. It improves secure object reconstruction. It reduces the risk of attacks.
Can secure serialization practices replace encryption for serialized data?
Secure serialization practices improve application security, but they cannot replace encryption. Encrypted payloads protect serialized data. Message authentication codes do too. Digital signatures and integrity verification help. Tamper detection is also important. These prevent unauthorized modification.
How do security testing methods identify unsafe deserialization mitigation gaps?
Security testing finds gaps. Static analysis can help. Dynamic analysis is useful. Vulnerability assessments are good. Penetration testing and code audits are important. Threat modeling also helps. These activities reveal weaknesses before attackers can exploit them.
What coding practices improve backend security against deserialization attacks?
Backend security improves with good practices. Follow defensive coding techniques. Use strict typing. Apply the principle of least privilege. Enable secure configuration. Implement audit logging. Handle exceptions safely. Consistently follow secure coding standards.
Lock Down Deserialization Before It Becomes a Breach
Insecure deserialization can turn trusted code into an easy target if you don’t lock it down. Start by reviewing risky serializers, enforce strict allowlists, and make validation part of every release. A few changes now can stop serious attacks later.
If you want your team to build these skills with real code, the Secure Coding Practices Bootcamp is a practical next step. It covers secure development through hands-on labs that developers can use right away. Join the Secure Coding Practices Bootcamp and start shipping safer code with confidence.
References
- https://learn.microsoft.com/pdf?url=https://learn.microsoft.com/en-us/dotnet/desktop/wpf/toc.json?view=netdesktop-8.0#18#7
- https://swc.rwth-aachen.de/docs/conferences/workshops/2022_QuASoQ/QuASoQ-2022-preprint.pdf#9#3