API1:2019 Некорректная Авторизация на Уровне Объектов
Источники угроз/Векторы атак | Недостатки безопасности | Последствия |
---|---|---|
Зависит от API : Сложность эксплуатации 3 | Распространенность 3 : Сложность обнаружения 2 | Технические последствия 3 : Зависит от бизнеса |
Злоумышленник может проэксплуатрировать уязвимые к некорректной авторизации на уровне объектов точки входа API, манипулируя идентификатором объекта, отправляемого в запросе. Это может привести к неавторизованному доступу к критичной информации. Это очень распространненая ситуация среди приложений базирующихся на API, потому что серверная часть не полностью отслеживает состояние клиента, а вместо это полагается на отправляемые клиентом параметры, например, идентификатор объекта, чтобы принять решение, к какому объекту осуществляется доступ. | Данная атака на API наиболее распространена и несет наибольшие последствия. Авторизация и механизмы контроля доступа в современных приложениях повсеместны и зачастую запутаны. Даже если проверки авторизации реализованы в приложении корректно, разработчики могут забыть добавить эти проверки перед доступом к критичным объектам. Автоматизированное статическое и динамическое тестирование, как правило, не обнаруживает проблемы в управлении доступом. | Неавторизованный доступ может привести к потере или манипуляции данными, а также разглашению данных лицам, не имеющим права доступа к ним. Кроме того неавторизованный доступ может привести к получению полного контроля над учетными записями. |
Как определить, является ли API уязвимым?
Авторизация на уровне объектов - это механизм управления доступом, реализуемый на уровне кода и проверяющий, что пользователь может получить доступ только к тем объектам, к которым у него должен быть доступ.
Каждая точка входа API, получающая идентификатор объекта и выполняющая любое действие с объектом, должна провести проверку авторизации на уровне объекта. Проверка должна удостовериться в том, что текущий пользователь действительно имеет право осуществить запрошенное действие над запрошенным объектом.
Некорректная работа этого механизма обычно приводит к неавторизованному разглашению или изменению данных, а также к их уничтожению.
Пример сценария атаки
Сценарий #1
Торговая онлайн платформа для онлайн магазинов предоставляет страницу с графиками доходов для каждого размещенного на платформе магазина. Злоумышленник, проанализировав отправляемые браузером запросы, может найти точки входа API, предоставляющие данные для графиков и определить формат запросов к ним /shops/{shopName}/revenue_data.json
. Используя другую точку входа API, злоумышленник может получить список названий всех магазинов, размещенных на платформе. Используя простой скрипт, заменяющий {shopName}
в URL запроса на названия магазинов, злоумышленник может получить доступ к данным о продажах тысяч онлайн магазинов.
Сценарий #2
Злоумышленник анализирует сетевой трафик носимого устройства, и HTTP PATCH
запрос, содержащий нестандартный HTTP заголовок X-User-Id: 54796
, привлекает его внимание. Изменив значение заголовка X-User-Id
на 54795
, злоумышленник получает ответ сервера, означающий успешную обработку запроса. Это означает, что злоумышленник может изменять данные учетных записей других пользователей.
Как предотвратить
- Надлежащим образом внедрить механизм авторизации, основывающийся на иерархии и политиках пользователей.
- Использовать механизм авторизации для проверки того, что текущий аутентифицированный пользователь имеет право доступа к запрошенному действию над записью в базе данных в каждой функции, использующей пользовательский ввод для доступа к записи.
- Использовать случайно сгенерированные значения, например, GUID в качестве идентификаторов записей в базе данных.
- Использовать тесты, проверяющие корректность работы механизма авторизации. Не пропускать уязвимые изменения, которые не проходят тесты.