Про уязвимости типа Path Traversal должен знать даже начинающий пентестер. И не только потому, что этот вопрос может попасться на собеседовании. Когда приложение начинает доверять пути из запроса больше, чем своей собственной логике, появляются те самые "../", позволяющие выбраться за пределы разрешённого каталога и добраться до конфигов, исходников, логов – всего, что процесс может прочитать.

OWASP формально относит Path Traversal к категории A01:2021 (Broken Access Control), но по факту, это ошибка валидации входных данных при работе с файловой системой, а не сбой в логике авторизации. И на практике Path Traversal остается актуальной угрозой даже в зрелых продуктах.

Яркий пример – уязвимости CVE-2024-5865 и CVE-2024-5866 в Centrify PAS. Первая из них позволяла читать произвольные файлы за счёт передачи пути с последовательностями типа ../, открывая доступ и к системным файлам, и к конфигурациям с ключами. А благодаря второй CVE можно было получать списки содержимого директорий за пределами корня приложения. Комбинация этих багов давала возможность сориентироваться в структуре каталогов, а затем прицельно считывать нужные файлы, давая полный доступ на чтение в пределах прав процесса.

Для систем, работающих с секретами (PAM, хранилища учётных данных), эксплуатация Path Traversal особенно неприятна. Случай из нашей практики: через обход каталогов с помощью Path Traversal забрали конфигурации с секретом для расшифровки шифротекста, который хранился в базе данных. А затем, используя SQL-инъекцию, вычитали зашифрованные строки с паролями, и использовали их для развития атаки.

Итого: незакрытая уязвимость Path Traversal ведёт к утечкам секретов, облегчает атакующим разведку и создаёт репутационные риски. При этом Path Traversal часто выглядит как «ошибка обработки строк», но по сути это проблема валидации входных данных. И даже единичная ошибка валидации пути, кажущаяся несущественной, может стать входной точкой в серьёзную цепочку компрометаций.

Как выявить Path Traversal на тестировании:

– Экспериментируйте с ../ в URL и параметрах, пробуйте различные энкодинги (%2e%2e%2f, %252e%252e%252f), используйте null bytes (%00).

– Тестируйте абсолютные пути (/etc/passwd, C:\windows\system32\drivers\etc\hosts) и длинные пути для обхода фильтров.

– Проверяйте работу с файловыми операциями в разных частях приложения: загрузка, экспорт, логи, бэкапы. Для разминки (в WebGoat или аналоге) можно погонять варианты с ../ и посмотреть логи: как атаку можно отследить? Помните, что Path Traversal легко упустить на ручном тестировании, если не проверять все файловые операции приложения.

«Взрослые» вендоры реагируют быстро при грамотном репорте: обе вышеописанные уязвимости были закрыты после нашего уведомления.

Как защищаться от Path Traversal:

– Не пускать пользовательский ввод напрямую в файловую систему. Вместо реальных имён файлов использовать контролируемые идентификаторы (UUID, хэши), а всю обработку путей на сервере делать через каноникализацию и проверку принадлежности целевого пути разрешённому корню. Любые «..», странные симлинки и попытки вывернуться за пределы директории должны отбрасываться.

– Изолировать пространство пользовательских файлов: отдельный логический диск/маунт, chroot или контейнеры в Unix, отдельная буква диска в Windows.

– Жёстко ограничивать права сервисного пользователя по принципу наименьших привилегий. Включить превентивные слои: сигнатуры WAF на обход каталогов, мониторинг и алерты по нетипичным путям в логах.

– Если вы пользуетесь Centrify PAS, проверьте версии и установите обновления. Своевременные патчи, правильный процесс управления уязвимостями, регулярный аудит и наблюдение за журналами – обязательная гигиена против Path Traversal.