OWASP API Security Top 10: 0xa1 broken object level authorization

# 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 в качестве идентификаторов записей в базе данных.
* Использовать тесты, проверяющие корректность работы механизма авторизации. Не пропускать уязвимые изменения, которые не проходят тесты.

## Ссылки

### Внешние

* [CWE-284: Improper Access Control][1]
* [CWE-285: Improper Authorization][2]
* [CWE-639: Authorization Bypass Through User-Controlled Key][3]

[1]: https://cwe.mitre.org/data/definitions/284.html
[2]: https://cwe.mitre.org/data/definitions/285.html
[3]: https://cwe.mitre.org/data/definitions/639.html