Класс багов, связанный с обходом пути на клиенте, становится всё более актуальным.
Классический path traversal (
../../../file) работает на сервере. Здесь идея та же, но на стороне клиента.👉 Пользовательский ввод влияет на путь → меняется, куда приложение делает запрос или редирект.
💡 В чём суть
Если приложение использует пользовательский ввод для формирования пути — появляется точка атаки.
Пример — сброс пароля:
https://target.com/reset/token?user=victim&Token=810128475189
Если значение
Token участвует в формировании пути или редиректа, его можно изменить:https://target.com/reset/token?user=victim&Token=810128475189%2F..%2F..%2Fuser
В результате клиент сформирует запрос:
https://target.com/user
💥 Где появляется импакт
Сам по себе редирект может быть безобидным. Но как только он используется вместе с другими механизмами, появляется реальный импакт:
➕вместе с уязвимостью open redirect,
➕при загрузке ресурсов (CSS/JS),
➕в логике маршрутизации SPA,
➕при динамической подгрузке данных.
Ресерчи по теме:
🔗 Client-Side Path Traversal: From Session Deletion to Full Account Compromise
🔗 Client Side Path Manipulation
🔗 Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF