В микросервисных приложениях фронт или gateway часто не обрабатывают запрос самостоятельно, а проксируют его во внутренний API. Именно здесь появляется нетривиальная поверхность атаки.
Как это выглядит ⤵️
Пользователь отправляет POST-запрос
/edit_user:{
"user_id": "456",
"username": "poc"
}Сервер берет
user_id и собирает внутренний запрос:POST /api/v1/users/456
Если путь к внутреннему API формируется из пользовательского ввода, пробуем path traversal:
{
"user_id": "../../admin/roles",
"username": "poc"
}В итоге бэкенд может обратиться к:
/api/v1/admin/roles
На выходе:
➡️ Обход роутинга
➡️ Доступ к внутренним или привилегированным эндпоинтам
➡️ Без прямого доступа к бэкенду
Даже если сервер не возвращает полный ответ от внутреннего API, многие приложения всё равно отдают коды статуса, флаги успешности или общие сообщения вроде
Permission denied. В более продвинутых кейсах внутренний API может обладать более высокими привилегиями или доступом к ограниченным эндпоинтам.
Как и при эксплуатации SSRF, ты используешь приложение в качестве прокси для обращения к внутренним сервисам — но уже через манипуляцию путями, а не через контроль URL.
Такой внутренний path traversal становится ещё опаснее, если его цеплять с уязвимостями вроде IDOR (для определения валидных путей к ресурсам) или с ошибочно настроенным контролем доступа (для эксплуатации внутренних ролей или токенов).
В конечном счете ты эксплуатируешь не файловую систему напрямую — ты перехватываешь логику бэкенда, заставляя его перемещаться по внутренним API-роутам способами, на которые он не был рассчитан.