OWASP API Security Top 10: 0xa5 broken function level authorization

# API5:2019 Некорректная Авторизация на Уровне Функций

| Источники угроз/Векторы атак | Недостатки безопасности | Последствия |
| - | - | - |
| Зависит от API : Сложность эксплуатации **3** | Распространенность **2** : Сложность обнаружения **1** | Технические последствия **2** : Зависит от бизнеса |
| Эксплуатация уязвимости предполагает, что злоумышленник может успешно отправить запросы в точки входа API, к которым у него не должно быть доступа. Эти точки входа могут быть доступны любому неаутентифицированному пользователю или аутентифицированному пользователю, не имеющему достаточных привилегий. Подобную ошибку легче обнаружить в API (по сравнению с традиционными приложениями), поскольку API более структурированы, а порядок доступа к определенным функциям более предсказуем (например, изменив метод HTTP запроса с GET на PUT, или изменив строку “users” в URL запроса на "admins"). | Проверки авторизации к функции или ресурсу обычно определяются на уровне конфигурации, иногда на уровне кода. Проведение проверок надлежащим образом - непростая и неоднозначная задача, поскольку современные приложения могут использовать много типов ролей и групп, а также иметь сложную иерархию пользователей (например, под-пользователей или пользователей с несколькими ролями). | Подобные ошибки позволяют злоумышленнику получить доступ к функционалу, минуя авторизацию. Административный функционал - ключевая цель атак этого типа. |

## Как определить, является ли API уязвимым?

Лучший способ найти проблемы с некорректной авторизацией на уровне объектов - провести глубокий анализ механизма авторизации, учитывая иерархию пользователей, различные роли и группы внутри приложения, а также задав себе следующие вопросы:

* Может ли обычный пользователь получить доступ к административным точкам входа?
* Может ли пользователь совершить критичные действия (например, создать, изменить или удалить объект), к которым у него не должно быть доступа, просто изменив метод HTTP запроса (например, с `GET` на `DELETE`)?
* Может ли пользователь из группы Х получить доступ к точке входа, доступной только пользователям из группы Y, просто угадав URL и параметры этой точки входа (например,  `/api/v1/users/export_all`)?

Неверно предполагать, что точка входа API является обычной или административной только на основании пути URL.

Зачастую разработчики открывают доступ к административным точкам входа по определенному относительному пути, например, `api/admins`. Однако очень часто административные точки входа находятся по другим относительным путям вместе с обычными точками входа, например, `api/users`.

## Примеры сценариев атаки

## Сценарий #1

В ходе процесса регистрации в приложении, которое позволяет регистрироваться только приглашенным пользователям, мобильное приложение отправляет следующий запрос к API `GET /api/invites/{invite_guid}`. Ответ содержит JSON с деталями приглашения, включая роль пользователя и его электронную почту.

Злоумышленник может дублировать запрос, изменив HTTP метод и точку входа на `POST /api/invites/new`. Только администраторы должны иметь доступ к этой точке входа через интерфейс администрирования, однако он не проводит проверки авторизации на уровне функций.

Проэксплуатировав уязвимость, злоумышленник может отправить себе приглашение с ролью администратора:

```
POST /api/invites/new

{“email”:”hugo@malicious.com”,”role”:”admin”}
```

### Сценарий #2

API содержит точку входа, которая должна быть доступна только администраторам `GET /api/admin/v1/users/all`. Эта точка входа возвращает данные всех пользователей и не проводит проверки авторизации на уровне функции. Злоумышленник, изучив структуру API, подбирает URL и получает доступ к точке входа, которая возвращает критичные данные пользователей приложения.

## Как предотвратить

В вашем приложении должен быть согласованный и легко анализируемый модуль авторизации, вызываемый всеми бизнес функциями. Зачастую такая защита предоставляется одной или несколькими компонентами вне кода приложения.

* Механизм, обеспечивающий выполнение проверок авторизации, должен запрещать весь доступ по умолчанию и требовать наличия определенных ролей для доступа к каждой из функций.
* Проверьте все точки входа API на предмет некорректной авторизации на уровне функций, принимая во внимание бизнес логику приложения и иерархию групп.
* Убедитесь, что все административные контроллеры наследуют абстрактный административный контроллер, в котором реализованы проверки авторизации на базе пользовательских групп и ролей.
* Убедитесь, что административные функции внутри обычных контроллеров проводят проверки авторизации на базе пользовательских групп и ролей.

## Ссылки

### OWASP

* [OWASP Article on Forced Browsing][1]
* [OWASP Top 10 2013-A7-Missing Function Level Access Control][2]
* [OWASP Development Guide: Chapter on Authorization][3]

### Внешние

* [CWE-285: Improper Authorization][4]

[1]: https://www.owasp.org/index.php/Forced_browsing
[2]: https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control
[3]: https://www.owasp.org/index.php/Category:Access_Control
[4]: https://cwe.mitre.org/data/definitions/285.html