Offensive security assessments
Deserialization Vulnerability
Serialization is the process of converting an object's state (such as data or a structure) into a format that can be easily stored, transmitted, or transferred, such as JSON, XML, or binary.
Why it matters
Serialization is the process of converting an object's state (such as data or a structure) into a format that can be easily stored, transmitted, or transferred, such as JSON, XML, or binary. Deserialization is the reverse process, where serialized data is converted back into the original object or structure that can be used by the program.
How we test it
Our operators follow a structured checklist for this topic, adapted to your API surface and authentication model.
Testing approach
- User Input: Test serialized data from forms, APIs, or URL parameters
- Session Management: Test serialized session data in cookies or session variables
- Cache Systems: Test serialized objects in caching systems like Redis or Memcached
- Inter-Service Communication: Test serialized data exchanged between services (APIs, microservices)
- Starts with rO0ABX (Base64 for AC ED 00 05) ➜ likely Java serialized object
- Sizeable base64 blobs in requests/cookies ➜ potential object data
- Random-looking long cookie values or JSON keys like serializedObject, stateData, contextBlob
- Error responses like:
What we look for
- User Input: Test serialized data from forms, APIs, or URL parameters
- Session Management: Test serialized session data in cookies or session variables
- Cache Systems: Test serialized objects in caching systems like Redis or Memcached
- Inter-Service Communication: Test serialized data exchanged between services (APIs, microservices)
- Starts with rO0ABX (Base64 for AC ED 00 05) ➜ likely Java serialized object
- Sizeable base64 blobs in requests/cookies ➜ potential object data
- Random-looking long cookie values or JSON keys like serializedObject, stateData, contextBlob
- Error responses like:
Related topics
| Topic | Summary |
|---|---|
| Application Logic Flaws | Application Logic Flaws occur when a web application's normal logic or workflow can be manipulated, allowing attackers to bypass security measures or misuse functionality in unexpected ways. |
| Arbitrary Cookie Flags | Cookies that hold session or sensitive data are set without the proper security flags (Secure, HttpOnly, SameSite). This lets cookies travel over cleartext, be read by JavaScript, or be sent on cross-site requests, enabling theft and CSRF. |
| Back Button Attack | After a user logs out (or on a shared device), pressing the browser Back button or reopening cached pages reveals sensitive data or restores an authenticated view. This happens when the server lets responses be cached and does not fully invalidate the session. |
| Broken Authentication | Flaws in how an application confirms a user's identity, letting attackers compromise passwords, tokens, or sessions and assume other users' identities. It is one of the highest-impact web risks (OWASP Top 10: Identification and Authentication Failures). |
| Brute Force Attack | An attacker systematically tries many credentials, tokens, or values until one works. It succeeds when an endpoint lacks rate limiting, lockout, or sufficient secret entropy. |
| Captcha Bypass | A CAPTCHA is meant to block automated requests, but flawed implementation lets attackers skip or solve it programmatically. Bypassing it re-enables brute force, spam, and other automation the control was meant to stop. |