# A01:2021 – Broken Access Control

**Алгоритм проверки**

1\. Сбор информации

- Определить роли в системе (guest, user, admin, API client).
- Зафиксировать все эндпоинты (через Burp/ZAP или документацию API).
- Проверить, какие ресурсы доступны без авторизации.

2\. Проверка 'горизонтального повышения привилегий' (Один пользователь получает доступ к данным другого)

- Изменить `id`, `user\_id`, `account`, `orderId` в URL/теле запроса.
- Удалить или подменить `session cookie / JWT`.
- Проверить доступ к чужим файлам (например, `/download/12345.pdf` → `/download/12346.pdf`).
- Использовать Burp Plugin \*\*Autorize\*\* – автоматически тестирует доступ к ресурсам других пользователей.

3\. Проверка 'вертикального повышения привилегий' (Обычный пользователь получает права администратора)

- Попробовать вызвать админские функции через API (например, `/admin/deleteUser`).
- Подменить роль в токене JWT (`"role":"user"` → `"role":"admin"`) и отправить запрос.
- Проверить скрытые кнопки/ссылки в интерфейсе (часто доступны через прямой URL).
- Использовать Burp Plugin \*\*AuthMatrix\*\* – строит матрицу ролей и проверяет, что доступ ограничен корректно.

4\. Проверка обхода контроля доступа

- Изменить HTTP-метод (`GET` → `POST`, `PUT` → `DELETE`).
- Удалить параметры авторизации (cookie, токены) и попробовать доступ.
- Использовать кеширующие прокси (nginx/apache misconfig) → проверить, не отдаются ли приватные данные без авторизации.
- Попробовать \*\*forced browsing\*\* (доступ к `/admin/` без ссылки).

5\. Проверка для API

- Запросить API-эндпоинты без токена → доступен ли ресурс.
- Подменить токен одного пользователя → получить доступ к данным другого.
- Проверить CORS-настройки (разрешены ли сторонние домены).
- Использовать Postman/Insomnia для ручных тестов.

6\. Проверка хранения сессий и токенов

- Проверить, что токен \*\*привязан к пользователю и роли\*\*.
- Проверить истечение токенов (можно ли использовать старые).
- Убедиться, что при смене пароля/выходе из аккаунта токены инвалидируются.

7\. Фиксация результатов

Для каждой проверки:

\* \*\*URL / endpoint\*\*  
\* \*\*Метод и параметры\*\*  
\* \*\*Ожидаемое поведение\*\* (например, отказ в доступе)  
\* \*\*Фактическое поведение\*\* (например, доступ разрешен)  
\* \*\*Уровень риска\*\* (High/Medium/Low)  
\* \*\*Рекомендации\*\* (RBAC, проверка ACL на сервере, строгая валидация ID и токенов)

**Практическая реализация**

Вот предложенный алгоритм проверки. Однако за этим (на самом деле стартовым) алгоритмом скрываются следующие вопросы:

- способ хранения и редактирования данных о сервере
- объем требуемых данных
- стэк используемых технологий
- глубина поиска и формат отчета

Разделим на black box и white box.

Например есть некий сервер. Начнем с директории с файлами и посмотрим, насколько это будет удобно.

1\. Сбор информации. Определить роли в системе (guest, user, admin, API client).