Кусочек из моей новой книги.

Напоминаю, что сейчас можно оформить предзаказ на данную книгу, по цене 899 ₽. На релизе цена будет 1299 ₽.
Содержание книги: https://vk.ru/@hacker_timcore-soderzhanie-knigi-myshlenie-hakera Глава 6. Эксплуатация бизнес-логики
- Нарушение контроля доступа (IDOR): когда код надежен, но логика абсурдна
Когда мы говорим о взломе, массовое сознание рисует картины внедрения сложных бинарных эксплойтов, переполнения буфера или расшифровки криптографических ключей. Индустрия информационной безопасности тратит миллиарды долларов на защиту от этих угроз: внедряются безопасные фреймворки, параметризованные SQL-запросы, многофакторная аутентификация и сложные алгоритмы шифрования.
Но что, если я скажу вам, что одна из самых разрушительных и распространенных уязвимостей в современном интернете вообще не связана с обходом криптографии или инъекциями кода? Что, если для получения полного доступа к финансовым документам, медицинским картам или личной переписке достаточно просто изменить одну цифру в адресной строке?
Добро пожаловать в мир Insecure Direct Object Reference (IDOR), который в современных классификациях API (OWASP API Top 10) получил название Broken Object Level Authorization (BOLA).
Слепота контроллеров: Аутентификация против Авторизации
Чтобы понять природу IDOR, необходимо четко разделить два фундаментальных понятия, которые разработчики постоянно путают: аутентификацию и авторизацию. Аутентификация отвечает на вопрос: «Кто ты такой?». Система проверяет ваш логин, пароль, OTP-код из SMS и выдает вам валидный токен сессии (например, JWT).Авторизация отвечает на вопрос:
«Имеешь ли ты право делать то, что просишь, с этим конкретным объектом?».
Паттерн мышления разработчика часто дает сбой на этапе транзита данных от интерфейса к базе данных. Представьте мобильное приложение клиники. Пользователь хочет посмотреть результаты своих анализов. Приложение отправляет HTTP-запрос:GET /api/v1/patients/8842/records HTTP/1.1Authorization:
Bearer <токен_пациента_8842>
Как мыслит создатель бэкенда? Он пишет middleware (промежуточный слой), который перехватывает запрос и проверяет JWT-токен. Подпись верна, срок действия не истек, пользователь легитимен. Middleware передает управление контроллеру базы данных. Контроллер берет цифру 8842 из URL, выполняет запрос SELECT * FROM records WHERE patient_id = 8842 и возвращает результат.
Код надежен. Никакой SQL-инъекции здесь нет, фреймворк всё заэкранировал. Но логика абсолютно абсурдна. Система убедилась, что запрос пришел от авторизованного клиента клиники. Но она забыла задать главный вопрос: «Принадлежит ли пациент с ID 8842 тому человеку, чей токен сейчас используется?».
Мы открываем Burp Suite, перехватываем этот запрос и меняем одну цифру:
GET /api/v1/patients/8843/records HTTP/1.1Authorization: Bearer <токен_пациента_8842>
Бэкенд снова проверяет наш токен (он по-прежнему валиден), берет из URL цифру 8843 и послушно отдает нам медицинскую карту чужого человека. Система поверила, что раз мы авторизованы в приложении, то имеем право запрашивать любые объекты, ID которых сможем угадать.
Weaponization: Автоматизация хаоса
В реальных условиях баг-хантер не перебирает цифры руками. Мы автоматизируем этот процесс, превращая единичную утечку в массовый дамп данных.
Используя инструмент Burp Suite Intruder (тип атаки Sniper), мы выделяем числовой идентификатор §8842§ как полезную нагрузку и загружаем словарь из 10 000 чисел. Intruder генерирует тысячи запросов в минуту, подставляя последовательные ID. Мы сортируем ответы по длине (Content-Length) и спокойно скачиваем всю базу данных клиники, просто просматривая те ответы, размер которых отличается от стандартной ошибки "Доступ запрещен" (хотя, при классическом IDOR, мы вообще не увидим ошибок).
Но настоящие профессионалы идут дальше. Они используют плагины вроде Autorize для Burp Suite. Этот плагин позволяет автоматизировать поиск IDOR в фоновом режиме. Мы авторизуемся в системе под двумя разными пользователями: Атакующий (с низкими привилегиями) и Жертва. Мы скармливаем плагину токен Атакующего и просто начинаем ходить по сайту от лица Жертвы.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 в мире. Но если в голове разработчика не возник вопрос «А имеет ли этот конкретный Вася право трогать эту конкретную запись?», вся эта защита превращается в декорации.
#blog #books #hacking #hacker