Понимание уязвимости IDOR в Google Crisis Map, которая раскрыла зарегистрированные адреса электронной почты
Google Crisis Map — устаревшая платформа, предназначенная для создания и обмена настраиваемыми картами, требовала от пользователей входа в систему с использованием аккаунтов Google для управления своими картами и настройками. Хотя сервис был направлен на упрощение совместной работы через общий доступ, в нем была обнаружена серьёзная уязвимость безопасности, связанная с небезопасными прямыми ссылками на объекты (IDOR) и инкрементальными идентификаторами пользователей, которая раскрыла адреса электронной почты тысяч зарегистрированных пользователей.
Введение в Google Crisis Map и его настройки домена
Используемый преимущественно для создания совместных карт, Google Crisis Map предоставлял функции создания, редактирования карт и управления доменом.
Для доступа к этим функциям пользователи должны были сначала пройти аутентификацию с помощью учетных данных Google.
После входа пользователи могли перейти к настройкам домена, где доступно несколько настраиваемых опций. Критическим элементом этих настроек является раздел Участники, в котором перечислены адреса электронной почты соавторов, имеющих доступ к картам. Через этот интерфейс можно приглашать других к совместной работе.
Анализ уязвимости: как управлялись участники
Добавление нового участника происходило посредством отправки POST-запроса на URL, устроенный следующим образом:
https://google.org/crisismap/example.com/.adminТело запроса содержало два ключевых поля:
new_user: адрес электронной почты пользователя, которого нужно добавитьnew_user.permission: уровень прав, присваиваемый пользователю
После отправки страница обновлялась, отображая нового участника в списке Участники вместе с его адресом электронной почты.
Инкрементальные идентификаторы пользователей в управлении правами
Анализ HTML-формы показал, что каждому адресу электронной почты участника соответствовал короткий числовой идентификатор, например, 123456, встроенный в атрибуты name полей ввода, связанных с уровнями доступа, а не сам адрес электронной почты.
Дополнительное исследование показало, что отправка формы с другим ID участника (например, 123457.permission) позволяла добавить этого пользователя в проект. Ключевым моментом было то, что это давало возможность увидеть адрес электронной почты этого пользователя в списке участников.
Эксплуатация IDOR для перечисления всех зарегистрированных адресов электронной почты
Идентификаторы пользователей были инкрементальными, начиная с 0 для первого зарегистрированного пользователя, затем 1 и так далее. Поскольку приложение не применяло строгие проверки авторизации для этих ID, злоумышленник мог последовательно увеличивать идентификаторы, добавляя произвольных пользователей в качестве участников и получая доступ к их адресам электронной почты.
Отсутствие контроля доступа к прямым ссылкам на объекты — классический пример уязвимости IDOR. Ее эксплуатация позволяла злоумышленнику перечислить адреса электронной почты всех зарегистрированных пользователей Google Crisis Map. На тот момент максимальный ID пользователя составлял около 32 000, что означало потенциальную утечку десятков тысяч адресов электронной почты.
Последствия уязвимости
- Риски для конфиденциальности: раскрытие адресов электронной почты нарушает приватность пользователей и способствует фишинговым и социально-инженерным атакам.
- Угрозы безопасности: злоумышленники могут использовать раскрытые списки для целевых атак, перебора учетных данных или рассылки спама.
- Целостность данных: несанкционированные изменения в списках участников могут нарушить легитимное сотрудничество.
Широкий контекст уязвимостей IDOR
IDOR остается одной из наиболее распространенных веб-уязвимостей. Согласно OWASP Top 10, проблемы неправильного контроля доступа приводят к утечкам данных во множестве систем по всему миру.
Масштабные атаки перечисления, подобные этой, подчёркивают необходимость надежных проверок авторизации при работе с такими ссылками, как идентификаторы пользователей, вместо полагания на безопасность через неочевидность.
Основные выводы и лучшие практики для предотвращения IDOR
- Реализуйте сильные проверки авторизации: убедитесь, что пользователи имеют доступ и могут выполнять действия только в пределах своих полномочий.
- Используйте неугадываемые идентификаторы: замените инкрементальные ID на случайные уникальные идентификаторы (UUID), чтобы затруднить перечисление.
- Валидация входных данных и контроль доступа: всегда проверяйте ссылки на объекты на стороне сервера перед обработкой запросов.
- Регулярные аудиты безопасности: постоянно тестируйте приложения на наличие IDOR и других уязвимостей с помощью автоматизированных сканеров и ручного пентестинга.
Хронология раскрытия уязвимости
| Дата | Событие |
|---|---|
| 12 декабря 2018 | Первое сообщение об уязвимости |
| 13 декабря 2018 | Приоритет изменен на P2, затем в тот же день повышен до P1 |
| 13 декабря 2018 | Начато расследование |
| 18 декабря 2018 | Выдана награда за безопасность, проблема устранена |
Заключение
Обнаружение уязвимости IDOR в платформе Google Crisis Map подчеркнуло важность строгого контроля доступа и риски, связанные с предсказуемыми инкрементальными идентификаторами пользователей. Этот инцидент служит напоминанием для организаций о необходимости постоянного мониторинга и защиты веб-приложений для сохранения данных пользователей и доверия.
Для веб-разработчиков и специалистов по безопасности важно применять лучшие практики, такие как использование непредсказуемых идентификаторов и жёсткие механизмы авторизации, чтобы предотвращать аналогичные ошибки безопасности.
Источники: