Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

Глоссарий

Что такое path traversal — чтение файлов, которые сервер не должен отдавать, через ../

Path traversal (directory traversal) подмешивает ../ во ввод имени файла, чтобы читать или писать файлы вне предусмотренной папки — .env, конфиги, ключи, /etc. Как это работает и реальная защита (не использовать ввод как путь; ограничивать базовым каталогом) — изложено в защитном ключе, без шагов атаки.

Опубликовано 2026-06-10 Обновлено 2026-06-10 3 мин чтения

«Подставьте ../ в поле имени файла, и глубоко лежащий на сервере .env станет читаемым» — это и есть path traversal. Вот как он работает и как его надёжно предотвратить (без шагов атаки).

Где он встречается

Везде, где «пользовательский ввод выбирает файл».

ФункцияОпасное использование
Скачивание / предпросмотрИспользование ?file= напрямую как имени файла
Показ изображения / вложенияПостроение части пути из параметра URL
ЗагрузкаИспользование имени от пользователя в пути сохранения (тип записи — самый опасный)
Загрузка шаблона / локалиДинамический выбор файла через ?lang= и т. п.

Почему это работает

../ означает «на уровень вверх». Если приложение склеивает публичную папку + пользовательский ввод и открывает этот файл, накопленные сегменты ../ позволяют запросу «выйти» из публичной папки.

Задумано: /var/www/files/ + пользовательский ввод
Ввод накапливает «уровень вверх» (../ ../ ../ …)
↓ приложение склеивает без нормализации, затем open()
Достигает за пределы базы (.env, конфиги, ключи, /etc) = чтение/запись
Склейте пользовательский ввод с базовой папкой, и накопленные ../ дотянутся до файлов вне её.

Чтение означает раскрытие; запись (загрузки) означает файлы, подброшенные куда угодно, что может привести к RCE.

Защита: не использовать ввод как путь + ограничивать базой

1

Никогда не используйте ввод как сырой путь (самое важное)

Разрешайте доступ к открытым файлам через allowlist «ID → реальный файл». Пользователь передаёт только идентификатор («3», «invoice»); сервер сам решает реальный путь.

2

Нормализуйте, затем проверяйте, что путь остаётся внутри базового каталога

Превратите его в абсолютный путь резолвером языка (resolve/realpath), затем проверьте, что он начинается с разрешённого базового каталога. Отклоняйте всё, что снаружи. Наивное вырезание строки '../' падает перед обходами через кодирование.

3

Запускайте приложение с минимальными привилегиями

Ограничьте файлы, которые может читать пользователь среды выполнения приложения, тем, что нужно для задачи. Даже если кто-то выберется, нечитаемые файлы ничего не раскроют.

4

Полностью держите секреты вне публичного корня

Не размещайте .env, .git, ключи или резервные копии в корне сайта или папке загрузок в принципе. Уберите поверхность атаки за счёт размещения.

Мнение этого сайта: это продолжение ошибок размещения — исправляйте в правильном порядке

Path traversal — продолжение инцидента с раскрытием .env: оба про «то, что никогда не должно быть достижимо через веб, становится достижимым через веб». Первая помощь (заголовки, наивные фильтры) скрывает симптом; если код и размещение не исправлены, другой путь всё равно утечёт. Порядок таков: (1) код, не использующий ввод как путь, (2) ограничение базовым каталогом, (3) держать секреты вне публичного корня. Читайте безопасное размещение на shared-хостинге вместе с этим, чтобы увидеть форму настоящего исправления.

Читать дальше

FAQ

QЧто утекает при path traversal?
A

Файлы, которые приложение никогда не должно было раскрывать: .env (учётные данные БД, API-ключи), конфигурационные файлы, закрытые ключи, исходный код, системные пути вроде /etc. Помимо чтения, если он достигает пути назначения загрузки, он может писать куда угодно и эскалировать до RCE (удалённого выполнения кода).

QКакая защита главная?
A

Никогда не используйте пользовательский ввод как сырой путь к файлу. Если приходится — отображайте его через allowlist (фиксированный набор ID/имён файлов), нормализуйте путь библиотекой и проверяйте, что результат остаётся внутри разрешённого базового каталога. Проверки расширения или наивное вырезание '../' обходятся.

QМожно ли просто заблокировать это через .htaccess или заголовки?
A

Это первая помощь для другой проблемы (чувствительные файлы, лежащие в корне сайта). Корневое исправление — размещение тела приложения, .env и .git ВНЕ публичного корня плюс код, не использующий ввод как путь. Первая помощь и настоящее исправление — разные задачи.