IDOR (Insecure Direct Object References): как получить чужие данные, просто изменив цифру в ссылке
IDOR — это одна из самых распространенных и до обидного простых в эксплуатации уязвимостей контроля доступа. Она возникает, когда приложение предоставляет прямой доступ к объектам (файлам, аккаунтам, записям в БД) по их идентификаторам, но забывает проверить, имеет ли текущий пользователь право просматривать этот конкретный объект.
— Разбираем механику подмены идентификаторов. Узнаем, почему банальное изменение ID в адресной строке или теле запроса позволяет скачивать чужие конфиденциальные документы гигабайтами.
В материале:
— Как работает IDOR: от банального user_id=1001 в URL до скрытых параметров в REST API-запросах
— Почему автоинкрементные ID (1, 2, 3...) в базе данных — это подарок для автоматизированных скраперов хакеров
— Масштабы последствий: массовая утечка персональных данных, просмотр чужих медицинских карт или кража платежных инвойсов
— Методы защиты: внедрение жесткой проверки прав владения на уровне бизнес-логики и переход на непредсказуемые UUID (GUID) вместо порядковых номеров
«Суть IDOR в том, что система отлично понимает, *какой* объект вы запрашиваете, но совершенно не интересуется тем, *кто* его запрашивает. Это как прийти в гардероб, назвать любой случайный номер и без лишних вопросов получить чужое пальто»
— резюмируют аудиторы безопасности.
🔗 Статья
// BACKDOOR
IDOR — это одна из самых распространенных и до обидного простых в эксплуатации уязвимостей контроля доступа. Она возникает, когда приложение предоставляет прямой доступ к объектам (файлам, аккаунтам, записям в БД) по их идентификаторам, но забывает проверить, имеет ли текущий пользователь право просматривать этот конкретный объект.
— Разбираем механику подмены идентификаторов. Узнаем, почему банальное изменение ID в адресной строке или теле запроса позволяет скачивать чужие конфиденциальные документы гигабайтами.
В материале:
— Как работает IDOR: от банального user_id=1001 в URL до скрытых параметров в REST API-запросах
— Почему автоинкрементные ID (1, 2, 3...) в базе данных — это подарок для автоматизированных скраперов хакеров
— Масштабы последствий: массовая утечка персональных данных, просмотр чужих медицинских карт или кража платежных инвойсов
— Методы защиты: внедрение жесткой проверки прав владения на уровне бизнес-логики и переход на непредсказуемые UUID (GUID) вместо порядковых номеров
«Суть IDOR в том, что система отлично понимает, *какой* объект вы запрашиваете, но совершенно не интересуется тем, *кто* его запрашивает. Это как прийти в гардероб, назвать любой случайный номер и без лишних вопросов получить чужое пальто»
— резюмируют аудиторы безопасности.
🔗 Статья
// BACKDOOR