елями: Атакующий (с низкими привилегиями) и Жертва. Мы скармливаем плагину токен Атакую... — 10 августа 2026 г. в 08:33:20.489
елями: Атакующий (с низкими привилегиями) и Жертва. Мы скармливаем плагину токен Атакующего и просто начинаем ходить по сайту от лица Жертвы.Autorize перехватывает каждый запрос Жертвы, делает его точную копию, подменяет токен на токен Атакующего и отправляет на сервер. Если сервер отвечает 200 OK на оба запроса - плагин подсвечивает строку красным цветом. Бинго! Мы нашли эндпоинт, который не проверяет принадлежность объекта. Эволюция защиты: Иллюзия UUID Разработчики не сидят сложа руки. Осознав, что последовательные числовые ID (1, 2, 3...) слишком легко подобрать, они перешли на использование UUID (Universally Unique Identifier) — длинных, псевдослучайных строк вида 550e8400-e29b-41d4-a716-446655440000. Архитектор системы выдыхает с облегчением. Сбрутфорсить UUID математически невозможно. Он считает, что решил проблему IDOR. Но это очередная иллюзия безопасности (Security through Obscurity). UUID защищает от перебора, но он не лечит саму уязвимость бизнес-логики - отсутствие проверки прав. Если мы не можем угадать ID, нам нужно просто найти место, где система сама отдаст нам чужие идентификаторы. Мышление хакера переключается на поиск утечек метаданных (Information Disclosure). Мы начинаем картографировать приложение. Мы находим публичный эндпоинт поиска пользователей: /api/users/search?q=John. Сервер возвращает нам список пользователей с именем John, и в этом ответе, помимо имен и аватарок, заботливо лежат их приватные UUID! Мы берем чужой UUID, возвращаемся к нашему уязвимому приватному эндпоинту (например, /api/messages/ + UUID), подставляем его туда и спокойно читаем чужую переписку. Разработчик спрятал ключ под коврик, но оставил неоновую вывеску с указанием, где именно лежит этот коврик. Слепые манипуляции и обход проверок типов Помимо чтения чужих данных (Read IDOR), существуют гораздо более деструктивные векторы - манипуляция состоянием (Write/Update IDOR).Что, если уязвимым окажется эндпоинт обновления пароля или привязки банковской карты? POST /api/settings/update{"user_id": 8843, "new_email": "hacker@evil.com"} Мы отправляем этот запрос с чужим ID. Если система уязвима, мы без ведома пользователя меняем его email, запрашиваем сброс пароля на свой ящик и полностью угоняем аккаунт. В сложных системах разработчики могут внедрять частичные проверки. Например, бэкенд ожидает строгий числовой тип. Если проверка всё же настроена криво, мы можем прибегнуть к HTTP Parameter Pollution (HPP) или массивам. Вместо user_id=8843 мы отправляем массив: user_id[]=8842&user_id[]=8843 (где 8842 - наш легитимный ID, чтобы пройти первичную валидацию, а 8843 - ID жертвы, к которому в итоге применится операция из-за десинхронизации парсинга на бэкенде). Истинная красота эксплуатации бизнес-логики заключается в том, что вы не боретесь с машиной. Вы боретесь с когнитивными искажениями архитектора. Код может быть покрыт тысячами юнит-тестов, использовать лучшую криптографию и сидеть за самым дорогим WAF в мире. Но если в голове разработчика не возник вопрос «А имеет ли этот конкретный Вася право трогать эту конкретную запись?», вся эта защита превращается в декорации.