Bug2Lab — Directory Traversal в скачивании логов

Directory Traversal в скачивании логов

Эндпоинт отдаёт файл лога по имени. Атакующий подставляет ../../.. и скачивает системные файлы (например, /etc/passwd). Фикс — нормализовать путь и запрещать выход за пределы разрешённой директории.

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

Атакующий вызывает:
/logs?file=../../../../etc/passwd
и получает содержимое системного файла.

GET /logs?file=../../../../etc/passwd
200 OK (text/plain)

root:x:0:0:root:/root:/bin/bash
dbuser:x:1001:1001:/home/dbuser:/bin/sh
...

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

Код просто делает new File("logs/"+fileParam) и читает то, что получилось. Никакой проверки, куда реально указывает путь.

Проблемный код
@GetMapping("/logs")
public String getLog(@RequestParam String file) throws IOException {
    File f = new File("logs/" + file); // ❌ может быть ../../../etc/passwd
    return Files.readString(f.toPath());
}

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

Нормализуем путь и проверяем, что он остаётся внутри разрешённой директории logs/. Если вылезли выше — сразу 403.

Исправленный паттерн
@GetMapping("/logs")
public String getLog(@RequestParam String file) throws IOException {
    Path base = Paths.get("logs").toAbsolutePath().normalize();
    Path requested = base.resolve(file).normalize();
    if (!requested.startsWith(base)) {
        throw new ResponseStatusException(HttpStatus.FORBIDDEN,"Invalid path"); // ✅
    }
    return Files.readString(requested);
}

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

Проверяем, что запрос с ../../ больше не возвращает 200 и не отдаёт системные файлы. Ожидаем 403.

#!/bin/bash # traversal-check.sh STATUS=$(curl -s -o /tmp/out.txt -w "%{http_code}" \ "https://staging.example.internal/logs?file=../../../../etc/passwd") if [ "$STATUS" = "200" ]; then echo "[BLOCK] Directory Traversal: можно читать системные файлы" exit 1 fi echo "[OK] Запрещён выход за пределы logs/ (HTTP $STATUS)" exit 0

Это гарантирует, что новый «просмотр логов» не станет окном в файловую систему.

Проверка пониманияГде корень проблемы?

Файл читался по пути, который полностью контролировал пользователь.

Приложение не проверяло, остаётся ли путь внутри допустимой директории.

Фикс — нормализовать путь и отказать, если он вылезает наружу.

Проблема была в отсутствии TLS.

Стандарт:никаких "отдай файл по имени, которое дал пользователь" без нормализации пути и белого списка директории.

Теория (по желанию) Traversal = «дай-ка я выйду из папки и посмотрю системные секреты»

📂1. В чём суть атаки?

Мы позволяем пользователю выбрать имя файла. Он вместо «today.log» даёт «../../../../etc/passwd». ОС воспримет это буквально и полезет вверх по директориям.

🔑2. Что можно украсть?

Конфиги с паролями к БД и ключами API.
Логи других сервисов.
Служебные ключи деплоя, токены, приватные ключи.

То есть иногда это прямой путь к полному компромиссу инфраструктуры.

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

«Саппорту нужно быстро скачать логи, давай сделаем /logs?file=…»
«Это же только для внутренних органов мониторинга, наружу не выйдет» — (потом выходит).
Не добавили проверку, что путь остаётся внутри /logs.

Это очень частая история «сервис для своих стал публичным».

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

Разрешён только фиксированный каталог, например logs/.
Мы нормализуем путь (normalize()) и проверяем startsWith(base).
Если путь вылез наружу — сразу 403, не 500.

Это должно стать чек-листом ревью кода для любых «скачай файл по имени» фич.

🚦5. Регресс зачем?

Даже если мы пофиксили /logs, завтра появится /downloadConfig?file=... от другой команды. Автотест, который пытается запросить ../../ и получить 200, сразу валит билд. Это автоматическое сдерживание, не устные договорённости.

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

Проверка пониманияГде корень проблемы?

Теория (по желанию) Traversal = «дай-ка я выйду из папки и посмотрю системные секреты» раскрыть

Теория (по желанию) Traversal = «дай-ка я выйду из папки и посмотрю системные секреты»