Detect PHP Object Injection: Logs, Tools and Blind Spots
Object injection hides in serialised data streams, bypassing input filters that target only string-based injection flaws like cross-site scripting (XSS).
Detect PHP object injection by monitoring for unexpected `unserialize()` calls in logs. Look for base64-encoded payloads in POST data that trigger file writes or command execution. Use runtime application protection tools to block dangerous deserialisation paths. Check for arbitrary file inclusion after deserialisation. Validate all untrusted data before processing.
Understanding the deserialisation risk
PHP object injection exploits the unserialize() function to reconstruct objects from a string. This process can trigger magic methods. Magic methods are special functions like __destruct() or __wakeup() that PHP calls automatically. An attacker crafts a string that, when deserialised, creates an object with specific properties. When the script ends or the object is accessed, the magic method executes. This execution happens before any standard input validation. The attacker gains control over the application flow. This bypasses security controls that only inspect the final output. The vulnerability exists wherever untrusted data reaches a deserialisation function.
Signal detection in application logs
Application logs provide the first line of defence against object injection. You must look for anomalies in request patterns. Standard web application firewalls often miss these attacks. The payloads are encoded and structured as data, not commands. Monitor your access logs for unusually long POST requests. These requests often contain base64-encoded strings. The string length exceeds typical form submissions. Look for requests targeting endpoints that handle file uploads or session management. These endpoints frequently use deserialisation. Check for errors related to class instantiation. These errors appear when the attacker tries to inflate a class that does not exist.
| Signal | Where to look | What it may mean |
|---|---|---|
| Long base64 strings | POST parameters in access logs | Attempted object serialisation payload |
| Class instantiation errors | PHP error logs | Attacker probing for vulnerable classes |
| Unexpected file writes | File system audit logs | Successful object injection leading to file inclusion |
| Rapid property changes | Application debug logs | Attacker manipulating object state for exploitation |
System behaviour anomalies
The system reacts differently when an object injection succeeds. The application may consume more memory than usual. This happens because the attacker creates complex object graphs. These graphs contain multiple nested objects. The memory spike occurs before the attack payload executes. You should monitor memory usage in real time. A sudden increase correlates with suspicious requests.
Check for new files appearing in writable directories. These files are often PHP scripts. The attacker writes them using a magic method. The script then includes this new file. This leads to remote code execution. Look for processes spawned by the web server. These processes may run shell commands. The command history may show unusual activity.
Tooling for identification
Static analysis tools help find vulnerable code. These tools scan source code for unserialize() calls. They identify where user input reaches these calls. However, static tools produce false positives. They cannot determine if the data is truly untrusted. Dynamic analysis tools monitor running applications. They intercept function calls at runtime. Runtime application protection platforms can block suspicious deserialisation. These tools inspect the object structure before creation. They compare it against known safe patterns. If the pattern matches an attack, the tool drops the request. This prevents the object from being created. Combining static and dynamic tools gives better coverage. Static tools find the entry points. Dynamic tools stop the exploitation.
Common blind spots in detection
Many teams focus on external inputs. They forget about internal data flows. Object injection often uses internal libraries. These libraries are trusted by the application. The deserialisation happens within the application code. External scanners cannot see these flows. Legacy code is another blind spot. Older applications may use session serialisation. They store objects in sessions without validation. When the session is read, the objects are deserialised. An attacker can tamper with the session cookie. This cookie is then sent back to the server. The server deserialises it and executes the payload. This bypasses input filters on standard forms. You must treat session data as untrusted.
The role of class autoloading
Modern PHP uses class autoloading. This feature loads classes on demand. It simplifies code management but introduces risk. An attacker can craft a payload that references a non-existent class. The autoloader tries to find the class definition. This trigger can be abused. The attacker provides a custom autoloader path. This path points to a malicious file. The file is included during the deserialisation process. This leads to arbitrary file inclusion. You must restrict autoloading to known directories. Do not allow user input to influence class paths. Validate the class name before loading. Ensure the class is part of your application. This prevents the autoloader from being weaponised.
Mitigation through configuration hardening
Configuration changes reduce the attack surface. You should disable unserialize() where possible. Use json_encode() and json_decode() instead. These functions handle data structures safely. They do not execute code. If you must use serialisation, use allow-lists. Define exactly which classes can be deserialised. Use a custom __sleep() method. This method controls what data is serialised. It prevents sensitive properties from being exposed. Implement __wakeup() to validate data. This method runs after deserialisation. It can check if the object state is valid. If not, it can destroy the object. This stops the attack chain.
Validating third-party dependencies
Third-party libraries often contain vulnerable code. You must audit these libraries regularly. Dependency confusion attacks can introduce malicious packages. These packages may contain backdoors. They can be used for object injection. Use a software composition tool. This tool tracks all dependencies. It alerts you when a new version is released. Check for known vulnerabilities in these versions. Apply out-of-band patches quickly. Do not wait for the next release cycle. Update your libraries to secure versions. This reduces the risk of inherited vulnerabilities. Keep your dependency list minimal. Fewer libraries mean fewer attack vectors.
Integrating with vulnerability scanning
Vulnerability scanners help identify weak points. They check for known CVEs. They do not find custom object injection flaws. You must combine scanning with manual testing. Manual testers craft specific payloads. They test each deserialisation point. This ensures coverage beyond automated tools. Integrate scanning into your deployment pipeline. Run scans before each release. This catches new vulnerabilities early. Fix issues before they reach production. This reduces the window of exposure. Regular scanning keeps your application secure. It complements runtime protection and static analysis.
Key takeaways
- Magic methods execute automatically during deserialisation, allowing code runs without direct function calls.
- Standard input sanitisation fails because object injection targets the structure of the data, not its content.
- Blind spots include trusted internal libraries and legacy code that implicitly trusts serialised session data.
Object injection bypasses standard input filters by abusing the deserialisation process. You must monitor for encoded payloads and restrict deserialisation to trusted classes.
Frequently asked questions
How do I distinguish object injection from cross-site scripting (XSS)?
XSS targets the browser by injecting scripts into web pages. Object injection targets the server by manipulating data structures during deserialisation. The payloads and impact differ significantly.
Can a CVSS score help prioritise these vulnerabilities?
A CVSS score provides a standardised risk rating. It helps you prioritise fixes based on severity. However, it does not detect the vulnerability. You still need testing and monitoring to find these flaws.
Is least privilege access effective against object injection?
Least privilege access limits the damage if an attack succeeds. It prevents the attacker from accessing sensitive files. It does not stop the injection itself. You must combine it with secure coding practices.
Do exposed admin panels increase the risk of this attack?
Exposed admin panels provide more entry points for attackers. They may contain functions that use deserialisation. Securing these panels reduces the attack surface. Ensure they are behind strong authentication.
How this guide was produced: written by the Firewall Pulse editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
