🤑 Эксплуатация IDOR через Path Traversal
Наткнулись на API-эндпойнт, как на первом скрине? Не проходите мимо: вполне вероятно, что перед вами IDOR.
Иногда вместо числового ID разработчики используют ключевые слова вроде me или current. API принимает оба варианта: и current, и 1234. Это делает IDOR-уязвимость менее заметной — но не менее опасной.
☑️ Что пробуем
1. Подставляем вместо current свой ID, например 1234.
2. Запрос проходит? Отлично.
3. Теперь вставляем ID другого пользователя.
4. Если эл. почта чужого аккаунта меняется — уязвимость подтверждена.
🧠 Более сложный пример
В больших проектах часто два API-сервера:
• фронтенд — для клиента;
• бэкенд — для внутренней логики.
Проблема в том, что права доступа проверяются только на фронтенде.
🚀 Подключаем Path Traversal
1. Отправляем /users/current/../1234/profile/email.
2. Фронтенд распознает current как ID пользователя и отправляет запрос на бэкенд.
3. Бэкенд получает путь /users/1234.
4. Проверки нет — можно менять чужие данные.
🎯 Что получаем
Возможность изменить эл. почту другого пользователя или получить доступ к его данным. Это полноценная IDOR-уязвимость, усиленная Path Traversal.
🧩 Вывод
Если API позволяет подставлять ID через ../, me, current (и т. п.) — это повод проверить на IDOR. Особенно если бэкенд не валидирует входные данные.
