Главная » Инф-ая безопасность » A01:2021- Нарушение контроля доступа

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

A01:2021- Нарушение контроля доступа
Инф-ая безопасность
11 ноябрь 2021
0

Обзор 


Переместился с пятой позиции. 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

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

Об авторе
admin Пользователь не указал информацию о себе
Ctrl
Enter
Заметили ошЫбку
Выделите текст и нажмите Ctrl+Enter
4 728
0
+44
Комментарии (0)