Перейти к содержанию

A01:2025 Нарушение контроля доступа icon

Общие сведения.

Сохраняя первое место в Top Ten, эта категория обнаружена в 100% протестированных приложений в той или иной форме. Среди наиболее значимых CWE: CWE-200: Раскрытие конфиденциальной информации неавторизованному субъекту, CWE-201: Раскрытие конфиденциальной информации через передаваемые данные, CWE-918 Подделка запросов на стороне сервера (SSRF) и CWE-352: Межсайтовая подделка запросов (CSRF). В этой категории наибольшее число встречаемостей в предоставленных данных и второе по величине число связанных CVE.

Таблица оценок.

Число CWE Макс. частота встречаемости Ср. частота встречаемости Макс. охват Ср. охват Ср. взвешенная эксплуатируемость Ср. взвешенное воздействие Общее число встречаемостей Общее число CVE
40 20,15% 3,74% 100,00% 42,93% 7,04 3,84 1 839 701 32 654

Описание.

Контроль доступа реализует политику, не позволяющую пользователям действовать за пределами предусмотренных для них разрешений. Нарушения, как правило, приводят к несанкционированному раскрытию информации, изменению или уничтожению данных либо к выполнению бизнес-функций за пределами возможностей пользователя. Распространённые уязвимости контроля доступа включают:

  • Нарушение принципа наименьших привилегий (deny by default): доступ должен предоставляться только для конкретных возможностей, ролей или пользователей, но фактически доступен всем.
  • Обход проверок контроля доступа путём изменения URL (манипуляции с параметрами или принудительный просмотр), внутреннего состояния приложения или HTML-страницы, либо с помощью инструмента атаки, изменяющего API-запросы.
  • Просмотр или редактирование чужой учётной записи путём предоставления её уникального идентификатора (небезопасные прямые ссылки на объекты).
  • Доступный API без контроля доступа для запросов POST, PUT и DELETE.
  • Повышение привилегий: действия от имени пользователя без входа в систему или получение привилегий сверх ожидаемых для вошедшего пользователя (например, доступ администратора).
  • Манипуляции с метаданными: повторное воспроизведение или подделка токена контроля доступа JSON Web Token (JWT), cookie или скрытого поля для повышения привилегий, а также злоупотребление аннулированием JWT.
  • Неправильная конфигурация CORS позволяет обращаться к API из неавторизованных или ненадёжных источников.
  • Принудительный просмотр (угадывание URL) для доступа к аутентифицированным страницам неаутентифицированным пользователем или к привилегированным страницам — обычным пользователем.

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

Контроль доступа эффективен только при реализации в надёжном серверном коде или serverless API, где злоумышленник не может изменить проверку контроля доступа или метаданные.

  • За исключением общедоступных ресурсов — запрет по умолчанию.
  • Реализуйте механизмы контроля доступа единожды и используйте их повторно во всём приложении, в том числе минимизируя использование Cross-Origin Resource Sharing (CORS).
  • Модели контроля доступа должны обеспечивать владение записями, не позволяя пользователям создавать, читать, обновлять или удалять любые записи.
  • Уникальные требования к бизнес-ограничениям приложения должны применяться доменными моделями.
  • Отключите листинг директорий веб-сервера и убедитесь, что метаданные файлов (например, .git) и резервные файлы не присутствуют в веб-корнях.
  • Журналируйте сбои контроля доступа, при необходимости оповещайте администраторов (например, при повторных сбоях).
  • Вводите ограничения скорости для доступа к API и контроллерам, чтобы минимизировать ущерб от автоматизированных инструментов атаки.
  • Сессионные идентификаторы с состоянием должны аннулироваться на сервере после выхода из системы. JWT-токены без состояния должны быть краткосрочными. Для долгосрочных JWT используйте токены обновления и следуйте стандартам OAuth для отзыва доступа.
  • Используйте хорошо зарекомендовавшие себя наборы инструментов или паттерны, обеспечивающие простой декларативный контроль доступа.

Разработчики и специалисты по контролю качества должны включать функциональный контроль доступа в модульные и интеграционные тесты.

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

Сценарий №1: Приложение использует непроверенные данные в SQL-запросе для доступа к информации об учётных записях:

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

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

https://example.com/app/accountInfo?acct=notmyacct

Сценарий №2: Злоумышленник просто принуждает браузер переходить к целевым URL. Для доступа к странице администратора требуются права администратора.

https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo

Если неаутентифицированный пользователь может получить доступ к любой из этих страниц — это уязвимость. Если пользователь без прав администратора может получить доступ к странице администратора — это также уязвимость.

Сценарий №3: Приложение реализует весь контроль доступа на стороне клиента. Несмотря на то что злоумышленник не может перейти к https://example.com/app/admin_getappInfo из-за JavaScript-кода в браузере, он может просто выполнить:

$ curl https://example.com/app/admin_getappInfo

из командной строки.

Ссылки.

Список связанных CWE