Авторка: Kateryna Ivanenko, Invicti Brand Manager
В современном мире с большим количеством API, одной из самых опасных и распространенных уязвимостей является нарушенная авторизация на уровне объектов (Broken Object Level Authorization, BOLA) — постоянно занимающая первые места в рейтинге OWASP Top 10 по безопасности API. Если ее не исправить, BOLA может позволить злоумышленникам получать доступ, изменять или удалять конфиденциальные данные, принадлежащие другим пользователям. В этой статье объясняется, что такое нарушенная авторизация на уровне объектов, как она работает и, самое главное, как ее предотвратить.
Что такое Broken Object Level Authorization?
BOLA возникает, когда программа не может правильно проверить, имеет ли пользователь право доступа к объекту, определенному с помощью определенного идентификатора.
Проще говоря, это означает, что если злоумышленник знает или угадывает идентификатор объекта, которым он не владеет, а система не обеспечивает надлежащую проверку авторизации, и таким образом преступник может получить доступ к нему или манипулировать этим объектом.
Почему Broken Object Level Authorization так опасна?
- Простота эксплуатации: атаки нарушенной авторизации на уровне объектов требуют минимальных навыков – часто это просто изменение идентификатора в URL-адресе или запросе к API.
- Утечка данных: несанкционированный доступ может раскрыть конфиденциальную информацию.
- Утрата репутации: такие инциденты могут быстро подорвать доверие клиентов.
- Нарушение соответствия: BOLA может вызвать регуляторные штрафы.
Как предотвратить уязвимость Broken Object Level Authorization
1. Внедрение надежного механизма авторизации, гарантирующего, что только пользователи с соответствующими разрешениями могут получать доступ или манипулировать определенными ресурсами.
Он должен быть:
- На основе ролей или атрибутов: разрешения нужно назначать на основе ролей пользователя (как администратор) или атрибутов (к примеру, отдел, регион).
- Контекстно-зависимым: учитывает не только то, кто является пользователем, но и то, к чему он пытается получить доступ и при каких условиях.
- Централизованным: использование централизованной системы контроля доступа для обеспечения согласованности и простоты аудита.
- Иерархически-зависимым: для организаций с многоуровневыми структурами.
2. Бэкенд должен проверять, имеет ли пользователь право доступа или изменения определенного ресурса каждый раз, когда предоставленный им идентификатор используется для получения данных или выполнения операции.
Рекомендации:
- Не доверять входным данным клиента: если пользователь отправляет действительный идентификатор, не факт, что ему разрешено получить к нему доступ.
- Всегда проверять право собственности или доступа: для каждого API-интерфейса, включающего посылание на объекты, обеспечить выполнение проверки бэкендом (например, «Владеет ли этот пользователь этим объектом?» или «Имеет ли этот пользователь разрешение на чтение этого объекта?»).
- Не полагаться на фильтры фронтенда: проверки авторизации должны производиться на сервере, а не на стороне клиента.
3. Использовать случайные идентификаторы, которые трудно угадать (такие как UUID или криптографически защищенные токены) для записей.
4. Проводить регулярное тестирование безопасности (например, DAST), включающее проверки авторизации на уровне объектов.
К примеру, платформа Invicti, объединившая Netsparker и Acunetix, имеет дополнительные настройки для аутентификации разными пользователями, что помогает выявить больше уязвимостей BOLA.
Чтобы бесплатно протестировать платформу и получить отчет OWASP Top 10 API Security от Invicti, свяжитесь с нами удобным для вас способом.
Вывод
Нарушенная авторизация на уровне объектов может представлять огромную угрозу даже тщательно разработанным программам. Поскольку API становятся сложнее, а данные более взаимосвязаными, отсутствие надежного контроля доступа на уровне объектов может привести к катастрофическим взломам, от которых важно защищаться.
