OWASP Топ-10 (2021) - General Software

OWASP Top 10 - это стандартный информационный документ для разработчиков и безопасности веб-приложений. Он представляет собой широкий консенсус в отношении наиболее критических рисков безопасности веб-приложений. Он признан разработчиками во всем мире как первый шаг к более безопасному кодированию.

Содержание

Использование OWASP Top 10 - это, возможно, самый эффективный первый шаг на пути к изменению культуры разработки программного обеспечения в вашей организации в сторону создания более безопасного кода.

Изменении в OWASP Топ-10

В Топ-10 на 2021 год появились три новые категории, четыре категории с изменениями в названиях и масштабах, а также некоторые консолидации.

A01:2021-Broken Access Control переместилась с пятого места; 94% приложений были проверены на наличие той или иной формы нарушения контроля доступа. 34 перечисления общих слабых мест (CWE), сопоставленные с нарушенным контролем доступа, встречались в приложениях чаще, чем в любой другой категории.
A02:2021-Cryptographic Failures переместился на одну позицию вверх и занял второе место, ранее известный как Sensitive Data Exposure, который был скорее симптомом, чем первопричиной. Вновь акцент здесь сделан на сбоях, связанных с криптографией, которые часто приводят к раскрытию конфиденциальных данных или компрометации системы.
A03:2021-Injection опустился на третью позицию. 94% приложений были проверены на наличие той или иной формы инъекций, а 33 CWE, отнесенные к этой категории, занимают второе место по количеству случаев в приложениях. Межсайтовый скриптинг теперь является частью этой категории в данном издании.
A04:2021-Insecure Design - это новая категория для 2021 года, в которой основное внимание уделяется рискам, связанным с недостатками дизайна. Если мы действительно хотим "двигаться влево" как индустрия, то это требует более широкого использования моделирования угроз, безопасных моделей и принципов проектирования, а также эталонных архитектур.
A05:2021-Security Misconfiguration поднялся с 6 места в предыдущем издании; 90% приложений были протестированы на наличие той или иной формы неправильной конфигурации. В связи с тем, что все большее число приложений переходит на высококонфигурируемое программное обеспечение, неудивительно, что эта категория поднялась вверх. Бывшая категория для XML External Entities (XXE) теперь является частью этой категории.
A06:2021-Vulnerable and Outdated Components ранее называлась Using Components with Known Vulnerabilities (Использование компонентов с известными уязвимостями) и находится на втором месте в Топ-10 по результатам опроса сообщества, а также имеет достаточно данных для попадания в Топ-10 по результатам анализа данных. Эта категория поднялась с № 9 в 2017 году и является известной проблемой, которую мы с трудом тестируем и оцениваем риск. Это единственная категория, в которой нет общих уязвимостей и экспозиций (CVE), сопоставленных с включенными в нее CWE, поэтому в их оценках учитывается стандартный вес эксплойта и воздействия, равный 5,0.
A07:2021-Identification and Authentication Failures ранее называлась Broken Authentication и сместилась со второго места, теперь она включает CWE, которые больше связаны с ошибками идентификации. Эта категория все еще является неотъемлемой частью Топ-10, но увеличение доступности стандартизированных рамок, похоже, помогает.
A08:2021-Software and Data Integrity Failures - новая категория для 2021 года, сфокусированная на принятии предположений, связанных с обновлениями программного обеспечения, критическими данными и CI/CD конвейерами без проверки целостности. Одно из самых высоких по весу воздействий из данных Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) сопоставлено с 10 CWE в этой категории. Небезопасная десериализация с 2017 года теперь является частью этой более крупной категории.
A09:2021-Security Logging and Monitoring Failures ранее называлась Insufficient Logging & Monitoring и добавлена по результатам отраслевого опроса (№ 3), поднявшись с № 10. Эта категория расширена и включает больше типов сбоев, ее сложно тестировать, и она не очень хорошо представлена в данных CVE/CVSS. Однако сбои в этой категории могут напрямую влиять на видимость, оповещение об инцидентах и криминалистику.
A10:2021-Server-Side Request Forgery добавлена из опроса сообщества Топ-10 (#1). Данные показывают относительно низкий уровень инцидентов при охвате тестирования выше среднего, а также оценки выше среднего по потенциалу эксплойта и воздействия. Эта категория представляет собой сценарий, в котором члены сообщества безопасности говорят нам, что это важно, хотя на данный момент это не показано в данных.

Список OWASP TOP 10 - 2021

A01:2021 - Нарушенный контроль доступа

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

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

A02:2021 - Сбои криптографии

Прежде всего, необходимо определить потребности в защите данных, находящихся в пути и в состоянии покоя. Например, пароли, номера кредитных карт, медицинские записи, личная информация и коммерческие секреты требуют дополнительной защиты, главным образом, если эти данные подпадают под действие законов о конфиденциальности, например, Общего регламента ЕС о защите данных (GDPR), или нормативных актов, например, о защите финансовых данных, таких как Стандарт безопасности данных PCI (PCI DSS). Для всех таких данных:

Передаются ли какие-либо данные открытым текстом? Это касается таких протоколов, как HTTP, SMTP, FTP, также использующих обновления TLS, например STARTTLS. Внешний интернет-трафик опасен. Проверьте весь внутренний трафик, например, между балансировщиками нагрузки, веб-серверами или внутренними системами.
Используются ли старые или слабые криптографические алгоритмы или протоколы по умолчанию или в старом коде?
Используются ли криптографические ключи по умолчанию, генерируются или повторно используются слабые криптографические ключи, отсутствует ли надлежащее управление ключами или их ротация? Проверяются ли криптографические ключи в репозиториях исходного кода?
Не обеспечивается ли шифрование, например, отсутствуют ли директивы безопасности в заголовках HTTP (браузера) или заголовки?
Проверен ли полученный сертификат сервера и цепочка доверия должным образом?
Игнорируются ли, повторно используются или не генерируются векторы инициализации, достаточно безопасные для криптографического режима работы? Используется ли небезопасный режим работы, такой как ECB? Используется ли шифрование, когда более подходящим является шифрование с аутентификацией?
Используются ли пароли в качестве криптографических ключей при отсутствии функции получения ключа на основе пароля?
Используется ли для криптографических целей случайность, которая не была разработана для удовлетворения криптографических требований? Даже если выбрана правильная функция, должна ли она быть засеяна разработчиком, а если нет, то не переписал ли разработчик встроенную в нее функцию сильного засева с засевом, не обладающим достаточной энтропией/непредсказуемостью?
Используются ли устаревшие хэш-функции, такие как MD5 или SHA1, или используются ли некриптографические хэш-функции, когда необходимы криптографические хэш-функции?
Используются ли устаревшие методы криптографической подшивки, такие как PKCS number 1 v1.5?
Можно ли использовать криптографические сообщения об ошибках или информацию побочного канала, например, в виде атак оракула на подшивку?

A03:2021 - Инъекции

Приложение уязвимо для атак, когда:

Данные, предоставляемые пользователем, не проверяются, не фильтруются и не санируются приложением.
Динамические запросы или непараметризованные вызовы без контекстно-зависимого экранирования используются непосредственно в интерпретаторе.
Враждебные данные используются в параметрах поиска объектно-реляционного отображения (ORM) для извлечения дополнительных конфиденциальных записей.
Враждебные данные используются напрямую или конкатенируются. SQL или команда содержит структуру и вредоносные данные в динамических запросах, командах или хранимых процедурах.

Некоторые из наиболее распространенных инъекций - SQL, NoSQL, команда ОС, объектно-реляционное отображение (ORM), LDAP, а также инъекция языка выражений (EL) или библиотеки навигации по объектному графику (OGNL). Концепция идентична для всех интерпретаторов. Анализ исходного кода - лучший метод обнаружения уязвимости приложений к инъекциям. Настоятельно рекомендуется автоматическое тестирование всех параметров, заголовков, URL, cookies, JSON, SOAP и XML данных. Организации могут включать инструменты статического (SAST), динамического (DAST) и интерактивного (IAST) тестирования безопасности приложений в конвейер CI/CD для выявления внедренных дефектов инъекций до развертывания производства.

A04:2021 - Небезопасный дизайн

Ненадежная разработка - это широкая категория, представляющая различные недостатки, выраженные как "отсутствующая или неэффективная схема контроля". Ненадежная конструкция не является источником всех других категорий риска Топ-10. Существует разница между ненадежной конструкцией и ненадежной реализацией. Мы проводим различие между дефектами проектирования и дефектами реализации не просто так: у них разные первопричины и способы устранения. Безопасный дизайн может иметь дефекты реализации, приводящие к уязвимостям, которые могут быть использованы. Небезопасный дизайн не может быть исправлен идеальной реализацией, поскольку по определению необходимые средства контроля безопасности никогда не создавались для защиты от конкретных атак. Одним из факторов, способствующих небезопасному дизайну, является отсутствие профилирования бизнес-рисков, присущих разрабатываемому программному обеспечению или системе, и, следовательно, неспособность определить, какой уровень безопасности необходим.

Требования и управление ресурсами

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

Безопасное проектирование

Безопасное проектирование - это культура и методология, которая постоянно оценивает угрозы и обеспечивает надежное проектирование и тестирование кода для предотвращения известных методов атак. Моделирование угроз должно быть интегрировано в сеансы доработки (или аналогичные мероприятия); ищите изменения в потоках данных и контроле доступа или других элементах управления безопасностью. При разработке пользовательских историй определите правильные потоки и состояния отказа, убедитесь, что они хорошо поняты и согласованы ответственными и затронутыми сторонами. Проанализируйте предположения и условия для ожидаемых и аварийных потоков, убедитесь, что они по-прежнему точны и желательны. Определите, как проверить предположения и обеспечить выполнение условий, необходимых для правильного поведения. Убедитесь, что результаты задокументированы в пользовательской истории. Учитесь на ошибках и предлагайте положительные стимулы для поощрения улучшений. Безопасная разработка - это не дополнение и не инструмент, который можно добавить к программному обеспечению.

Жизненный цикл безопасной разработки

Безопасное программное обеспечение требует безопасного жизненного цикла разработки, определенного шаблона безопасного проектирования, методологии проложенной дороги, библиотеки защищенных компонентов, инструментария и моделирования угроз. Обращайтесь к специалистам по безопасности в начале программного проекта на протяжении всего проекта и сопровождения программного обеспечения. Рассмотрите возможность использования OWASP Software Assurance Maturity Model (SAMM), чтобы помочь структурировать ваши усилия по разработке безопасного программного обеспечения.

A05:2021 - Неправильная конфигурация системы безопасности

Приложение может быть уязвимым, если оно:

Отсутствует соответствующее усиление безопасности в любой части стека приложений или неправильно настроены разрешения на облачные сервисы.
Включены или установлены ненужные функции (например, ненужные порты, службы, страницы, учетные записи или привилегии).
Учетные записи по умолчанию и их пароли включены и не изменены.
При обработке ошибок пользователям выдаются трассировки стека или другие слишком информативные сообщения об ошибках.
В обновленных системах последние функции безопасности отключены или не настроены безопасно.
Параметры безопасности в серверах приложений, фреймворках приложений (например, Struts, Spring, ASP.NET), библиотеках, базах данных и т.д. не установлены на безопасные значения.
Сервер не отправляет заголовки или директивы безопасности, или они не установлены на безопасные значения.
Программное обеспечение устарело или уязвимо (см. A06:2021-Уязвимые и устаревшие компоненты).
Без согласованного, повторяющегося процесса конфигурирования безопасности приложений системы подвергаются повышенному риску.

A06:2021 - Уязвимые и устаревшие компоненты

Скорее всего, вы уязвимы:

Если вы не знаете версии всех используемых вами компонентов (как на стороне клиента, так и на стороне сервера). Сюда входят компоненты, которые вы используете напрямую, а также вложенные зависимости.
Если программное обеспечение уязвимо, не поддерживается или устарело. Сюда входят ОС, сервер веб-приложений, система управления базами данных (СУБД), приложения, API и все компоненты, среды выполнения и библиотеки.
Если вы не проводите регулярное сканирование на наличие уязвимостей и не подписываетесь на бюллетени безопасности, касающиеся используемых вами компонентов.
Если вы не исправляете и не обновляете базовую платформу, фреймворки и зависимости своевременно и с учетом рисков. Обычно это происходит в средах, где исправление является ежемесячной или ежеквартальной задачей в рамках контроля изменений, в результате чего организации могут несколько дней или месяцев не подвергаться ненужному воздействию исправленных уязвимостей.
Если разработчики программного обеспечения не проверяют совместимость обновленных, модернизированных или исправленных библиотек.
Если вы не обеспечиваете безопасность конфигураций компонентов (см. A05:2021 - Неправильная конфигурация системы безопасности).

A07:2021 - Сбои идентификации и аутентификации

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

допускает автоматические атаки, такие как вброс учетных данных, когда у злоумышленника есть список действительных имен и паролей.
Разрешает перебор или другие автоматические атаки.
Разрешает использовать стандартные, слабые или хорошо известные пароли, такие как "Password1" или "admin/admin".
Использует слабые или неэффективные процессы восстановления учетных данных и забытых паролей, такие как "ответы на основе знаний", которые невозможно сделать безопасными.
Используются хранилища данных с открытым текстом, зашифрованными или слабо хэшированными паролями (см. A02:2021-Cryptographic Failures).
Имеет отсутствующую или неэффективную многофакторную аутентификацию.
Раскрывает идентификатор сессии в URL.
Повторное использование идентификатора сессии после успешного входа в систему.
Неправильно аннулирует идентификаторы сеансов. Пользовательские сессии или маркеры аутентификации (в основном маркеры единого входа (SSO)) не аннулируются должным образом при выходе из системы или в период бездействия.

A08:2021 - Нарушения целостности программного обеспечения и данных

Нарушения целостности программного обеспечения и данных связаны с кодом и инфраструктурой, которые не защищают от нарушений целостности. Примером может служить ситуация, когда приложение использует плагины, библиотеки или модули из ненадежных источников, репозиториев и сетей доставки контента (CDN). Небезопасный конвейер CI/CD может создать потенциал для несанкционированного доступа, вредоносного кода или компрометации системы. Наконец, многие приложения сегодня включают функцию автоматического обновления, когда обновления загружаются без достаточной проверки целостности и применяются к ранее доверенному приложению. Злоумышленники потенциально могут загружать собственные обновления для распространения и запуска на всех установках. Другой пример, когда объекты или данные кодируются или сериализуются в структуру, которую злоумышленник может увидеть и изменить, уязвим для небезопасной десериализации.

A09:2021 - Сбои в регистрации и мониторинге безопасности

Возвращаясь к OWASP Top 10 2021, эта категория призвана помочь в обнаружении, эскалации и реагировании на активные нарушения. Без регистрации и мониторинга невозможно обнаружить нарушения. Недостаточное протоколирование, обнаружение, мониторинг и активное реагирование происходит в любое время:

События, подлежащие аудиту, такие как входы в систему, неудачные входы в систему и высокоценные транзакции, не регистрируются.
Предупреждения и ошибки не генерируют никаких, неадекватных или неясных сообщений в журнале.
Журналы приложений и API не отслеживаются на предмет подозрительной активности.
Журналы хранятся только локально.
Соответствующие пороги оповещения и процессы эскалации реакции не установлены и не эффективны.
Тестирование на проникновение и сканирование инструментами динамического тестирования безопасности приложений (DAST) (например, OWASP ZAP) не вызывают оповещений.
Приложение не может обнаружить, эскалировать или предупредить об активных атаках в реальном или близком к реальному времени.
Вы уязвимы к утечке информации, делая события регистрации и оповещения видимыми для пользователя или злоумышленника (см. A01:2021-Сломанный контроль доступа).

A10:2021 - Подделка запросов со стороны сервера (SSRF)

Дефект SSRF возникает, когда веб-приложение получает удаленный ресурс без проверки URL, предоставленного пользователем. Это позволяет злоумышленнику заставить приложение отправить подделанный запрос в неожиданное место назначения, даже если оно защищено брандмауэром, VPN или другим типом списка контроля доступа к сети (ACL).

Поскольку современные веб-приложения предоставляют конечным пользователям удобные функции, получение URL-адреса становится обычным сценарием. В результате частота возникновения SSRF растет. Кроме того, серьезность SSRF становится выше из-за облачных сервисов и сложности архитектур.