Bug2Lab — Небезопасная десериализация Java-объектов

Небезопасная десериализация Java-объектов

Приложение принимает сериализованный объект (например, Base64), десериализует его через ObjectInputStream и верит ему. Атакующий может подсунуть объект с вредоносным кодом и добиться RCE.

Как выглядит атака

Атакующий шлёт специально сконструированный сериализованный объект в /api/restore. Приложение десериализует его и выполняет вредоносный код при readObject().

POST /api/restore
Body: base64(...serialized payload...)

200 OK
{ "status":"restored" }

Почему это стало возможным

Код слепо десериализует входящий объект. Нет вайтлиста разрешённых типов, нет валидации.

Проблемный код
@PostMapping("/api/restore")
public String restore(@RequestBody String rawBase64) throws Exception {
    byte[] data = Base64.getDecoder().decode(rawBase64);
    ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
    Object obj = ois.readObject(); // ❌ может быть что угодно с gadget-цепочкой
    // ...
    return "{\"status\":\"restored\"}";
}

Как это чинится правильно

Не принимать «сырую Java-сериализацию» вообще. Использовать безопасные форматы (JSON DTO) и жёстко маппить поля.

Исправленный паттерн
@PostMapping("/api/restore")
public String restore(@RequestBody RestoreRequest dto) {
    // ✅ Чётко описанный DTO, Jackson маппит только ожидаемые поля
    service.restore(dto.getSnapshotId(), dto.getData());
    return "{\"status\":\"restored\"}";
}

bug2regressРегрессионный тест

Тест отправляет заведомо «левый» сериализованный объект. Если сервис всё ещё пытается десериализовать через ObjectInputStream и отвечает 200 — билд стопаем. Ожидаем 400/403.

#!/bin/bash # deserialization-check.sh MALICIOUS=$(cat malicious_payload.base64) STATUS=$(curl -s -o /tmp/resp.json -w "%{http_code}" \ -X POST \ -H "Content-Type: text/plain" \ --data "$MALICIOUS" \ https://staging.example.internal/api/restore) if [ "$STATUS" = "200" ]; then echo "[BLOCK] Небезопасная десериализация всё ещё включена" exit 1 fi echo "[OK] Сырая десериализация объектов больше не допускается (HTTP $STATUS)" exit 0

Это закрывает путь к удалённому выполнению кода внутри вашего сервиса.

Проверка пониманияЧто было критичным?

Сервис десериализовал произвольный объект, полученный от клиента.

Это могло привести к выполнению произвольного кода внутри процесса.

Решение — перейти на строгий DTO/json и не вызывать напрямую ObjectInputStream на пользовательских данных.

Проблема была в том, что не использовался HTTPS.

Стандарт:мы не принимаем "сырые сериализованные Java-объекты" от клиента. Только валидированные DTO.

Теория (по желанию) Сырая десериализация = прямой вход в ваш процесс

🧠1. Что делает десериализация?

Мы берём массив байтов и превращаем его обратно в Java-объект. Проблема: при этом могут вызываться конструкторы, геттеры/сеттеры, readObject() и другие «магические» методы классов. Если класс «ядовитый», он может выполнить код уже в момент десериализации.

💥2. Почему это почти всегда RCE-риск?

Есть целые «гаджет-цепочки» — готовые классы из популярных библиотек, которые при десериализации вызывают, например, Runtime.exec(). Атакующий просто лепит объект из этих классов и отправляет вам. Если вы десериализуете вслепую — он запускает команды на вашем сервере.

🧪3. Почему разработчики так делают?

«Нужно быстро сохранить состояние в backup и потом восстановить».
«ObjectInputStream же удобно, зачем писать DTO?»
«Это же внутренняя ручка, не наружу» — пока её не прокинул кто-то наружу «временно».

📏4. Новый стандарт

❌ Не принимать произвольные сериализованные Java-объекты снаружи.
✅ Принимать только чётко описанные структуры (DTO), маппить через Jackson и валидировать поля.
⚠ Если по какой-то причине нужна бинарная форма — whitelist классов и ручная проверка.

То есть «ObjectInputStream на пользовательском вводе» = красный флаг.

🚦5. Автотесты и пайплайн

Регрессионный тест шлёт заведомо опасный payload. Если сервис возвращает 200 — мы блокируем релиз. Это реальная защита от «кто-то снова включил удобное восстановление snapshot-а».

bug2regressРегрессионный тест

Проверка пониманияЧто было критичным?

Теория (по желанию) Сырая десериализация = прямой вход в ваш процесс раскрыть

Теория (по желанию) Сырая десериализация = прямой вход в ваш процесс