Deserialization Attacks – jak niebezpieczna jest (de)serializacja danych?
🧬 Deserialization Attacks – jak niebezpieczna jest (de)serializacja danych?
Deserialization Attack to rodzaj ataku na aplikacje, które przetwarzają dane w zserializowanej formie. Gdy aplikacja deserializuje niezaufane dane bez odpowiedniej weryfikacji, napastnik może przesłać specjalnie przygotowany obiekt, który podczas deserializacji wykonuje nieautoryzowany kod, omija zabezpieczenia lub modyfikuje zachowanie programu.
🧠 Czym jest serializacja i deserializacja?
- Serializacja – proces konwersji obiektu (np. klasy w Javie, Pythonie, PHP) do formatu, który można przechować lub przesłać (np. JSON, XML, binarny).
- Deserializacja – proces odwrotny, przekształcenie danych z formatu pośredniego z powrotem do obiektu w programie.
👉 Problem pojawia się, gdy aplikacja deserializuje dane pochodzące od użytkownika bez walidacji – bo wówczas użytkownik może wprowadzić złośliwy obiekt.
💣 Przykład ataku – Java i ObjectInputStream
Java umożliwia serializację obiektów za pomocą ObjectOutputStream i odtworzenie ich przez ObjectInputStream.
Przykład zagrożenia:
ObjectInputStream in = new ObjectInputStream(clientSocket.getInputStream());
Object obj = in.readObject(); // niezweryfikowany obiekt!
Atakujący może stworzyć klasę z niestandardową implementacją readObject() lub finalize(), która wykona złośliwy kod po deserializacji.

⚙️ Jakie są skutki ataku?
- 🔓 Remote Code Execution (RCE)
- 🔧 Zmiana stanu obiektów w pamięci
- 📤 Eksfiltracja danych
- 🔁 Zmiana logiki aplikacji
- 🕵️♂️ Wykonanie poleceń systemowych
🧪 Znane frameworki i podatne technologie
Deserialization Attacks dotyczą wielu popularnych języków:
| Język / technologia | Mechanizmy podatne |
|---|---|
| Java | ObjectInputStream, Apache Commons Collections |
| PHP | unserialize() bez allowed_classes |
| Python | pickle.loads(), yaml.load() |
| .NET (C#) | BinaryFormatter.Deserialize() |
| Ruby | Marshal.load() |
| Node.js | serialize-javascript, podatne pakiety npm |
🔥 Przykład ataku w PHP
class User {
public $isAdmin = false;
}
$input = $_COOKIE['data'];
$user = unserialize($input);
if ($user->isAdmin) {
echo "Witaj, administratorze!";
}
Atakujący może przesłać cookie z wartością:
O:4:"User":1:{s:7:"isAdmin";b:1;}
Co powoduje, że $user->isAdmin staje się true, umożliwiając eskalację uprawnień.
🧰 Narzędzia i frameworki używane do ataków
- ysoserial (Java) – generowanie payloadów RCE
- PHPGGC – generowanie obiektów gadżetów do PHP unserialize
- ysoserial.net – wersja dla .NET
- Burp Suite – do manualnej modyfikacji danych serializowanych
- GadgetProbe – detekcja klas podatnych na deserializację
🔐 Jak zabezpieczyć aplikację?
✅ Najważniejsze zasady:
- Nigdy nie deserializuj danych od użytkownika bez walidacji
- Używaj bezpiecznych formatów danych (np. JSON zamiast binarnej serializacji)
- W PHP – używaj
unserialize($data, ['allowed_classes' => false]) - W Java – implementuj
ObjectInputValidationi filtruj klasy - W Pythonie – unikaj
pickle; jeśli musisz, używajpickle.loads()tylko na zaufanych danych - Monitoruj deserializację i loguj nietypowe błędy
🔍 Detekcja i analiza forensic
- 🔎 W logach mogą pojawić się wyjątki typu
ClassNotFoundException,InvalidClassException - 📈 Anomalie w danych przesyłanych do aplikacji (np. dziwne base64)
- 💬 Debugowanie błędów logicznych wynikających z manipulacji stanem obiektów
- 🧱 Sandboxowanie i testy fuzzingowe API
📚 Znane przypadki ataków
- Apache Commons Collections (Java) – podatności wykorzystywane przez
ysoserial - Magento (PHP) – podatność RCE przez
unserialize()(CVE-2015-1397) - Ruby on Rails – ataki RCE przez
YAML.load() - Jenkins – wiele podatności RCE związanych z deserializacją
🚨 Deserialization w OWASP Top 10
W OWASP Top 10 ataki deserializacyjne zostały sklasyfikowane jako część:
A08:2021 – Software and Data Integrity Failures
Jest to zagrożenie wynikające z braku kontroli nad integralnością zaufanych obiektów i danych – w tym właśnie deserializacji.
🧩 Podsumowanie
Deserialization Attacks to poważne zagrożenie, które może prowadzić do eskalacji uprawnień, wykonania kodu, zmiany logiki aplikacji czy kradzieży danych. Szczególnie niebezpieczne w dużych aplikacjach opartych na frameworkach z wieloma zależnościami.






