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

Обзор 

Переместился с пятой позиции. 94 % приложений были протестированы на наличие той или иной формы нарушения контроля доступа со средним коэффициентом инцидентности 3,81 %. И в предоставленном наборе данных больше всего случаев (более чем 318 тыс.) Известные CWE: CWE-200: Раскрытие конфиденциальной информации Неавторизованному Субъекту, CWE-201: Раскрытие конфиденциальной информации через Отправленные данные и CWE-352: Межсайтовая Подделка запросов.

Описание

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

• Нарушение принципа наименьших привилегий или отказа по умолчанию, когда доступ должен предоставляться только для определенных возможностей, ролей или пользователей, но доступен любому.
• Обход проверок контроля доступа путем изменения URL-адреса (изменение параметров или принудительный просмотр), состояния внутреннего приложения или HTML-страницы или с помощью средства атаки, изменяющего запросы API.
• Разрешение просмотра или редактирования чужой учетной записи путем предоставления ее уникального идентификатора (небезопасные прямые ссылки на объекты)
• Доступ к API с отсутствующими элементами управления доступом для ПУБЛИКАЦИИ, РАЗМЕЩЕНИЯ и УДАЛЕНИЯ.
• Повышение привилегий. Действовать как пользователь без входа в систему или действовать как администратор при входе в систему как пользователь.
• Обращение с метаданными, такие как воспроизведение или изменение маркера контроля доступа JSON Web Token (JWT), или файла cookie или скрытого поля, управляемого для повышения привилегий или злоупотребления недействительностью
• Неправильная конфигурация CORS позволяет осуществлять доступ к API из неавторизованных/ненадежных источников.
• Принудительный просмотр аутентифицированных страниц как пользователь, не прошедший проверку подлинности, или привилегированных страниц как обычный пользователь.

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

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

• Запрещайте доступ по умолчанию, кроме общедоступных ресурсов.
• Внедрите механизмы контроля доступа один раз и повторно используйте их во всем приложении, включая минимизацию совместного использования ресурсов между разными источниками (CORS).
• Элементы управления доступом модели должны обеспечивать владение записями, а не соглашаться с тем, что пользователь может создавать, читать, обновлять или удалять любую запись.
• Модели доменов должны выполнять уникальные требования к бизнес-ограничениям приложений.
• Отключите список каталогов веб-сервера и убедитесь, что метаданные файлов (например, .git) и файлы резервных копий отсутствуют в web roots.
• Регистрируйте сбои контроля доступа, предупреждайте администраторов, когда это необходимо (например, повторные сбои).
• Ограничьте скорость доступа к 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

Если пользователь, не прошедший проверку подлинности, или не администратор может получить доступ к любой странице, это недочет.