OWASP TOP 10

• Общее описание
• A01:2021 – Broken Access Control

Общее описание

Проект Open Worldwide Application Security Project (OWASP) - это открытое сообщество, призванное предоставить организациям возможность разрабатывать, приобретать и обслуживать приложения и API, которым можно доверять.

Это минимум для оценки защищенности. Одна из трудностей использования OWASP Top 10 в качестве стандарта заключается в  документации рисков и проблем, которые не всегда легко поддаются тестированию.

Выбор между Top 10 и OWASP Application Security Verification Standard

Use Case	OWASP Top 10 2021	OWASP Application Security Verification Standard
Осознание	Да
Тренировка	Базовый уровень	Комплексный
Дизайн и архитектура	Изредка	Да
Стандарт программирования	Минимум	Да
Проверка защищенного кода	Минимум	Да
Контрольный список для экспертной оценки	Минимум	Да
Модульное тестирование	Изредка	Да
Интеграционное тестирование	Изредка	Да
Тестирование на проникновение	Минимум	Да
Поддержка инструментов	Минимум	Да
Secure Supply Chain	Изредка	Да

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

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

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

• Обход проверок контроля доступа путем изменения URL-адреса (изменение параметров или принудительный просмотр), внутреннего состояния приложения или HTML-страницы или с помощью средства атаки, изменяющего запросы API.

• Разрешение на просмотр или редактирование чужой учетной записи путем предоставления ее уникального идентификатора (небезопасные прямые ссылки на объекты).

• Доступ к API с отсутствующими элементами управления доступом для POST, PUT и DELETE.

• Повышение привилегий. Действия от имени пользователя без входа в систему или действия от имени администратора при входе в систему в качестве пользователя.

• Манипуляции с метаданными, такие как воспроизведение или подделка токена управления доступом к веб-токену JSON (JWT), cookie или скрытому полю, которые используются для повышения привилегий или для аннулирования JWT.

• Неправильная настройка CORS допускает доступ к API из несанкционированных/ ненадежных источников.

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

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

Способы защиты:

• За исключением общедоступных ресурсов, по умолчанию доступ запрещен.

• Внедрите механизмы контроля доступа один раз и повторно используйте их во всем приложении, включая минимизацию использования ресурсов разных источников (CORS).

• Средства управления доступом должны обеспечивать соблюдение права собственности данных, а не допускать, что пользователь может создавать, читать, обновлять или удалять любые данные.

• Модели должны обеспечивать соблюдение уникальных требований к бизнес-лимитам приложений.

• Отключите список каталогов веб-сервера и убедитесь, что метаданные файлов (например, .git) и файлы резервных копий отсутствуют в корневом каталоге веб-сервера.

• Регистрируйте сбои в системе контроля доступа и при необходимости предупреждайте администраторов (например, о повторяющихся сбоях).

• Ограничьте скорость доступа к API и контроллеру, чтобы минимизировать ущерб от автоматизированных средств атаки.

• Идентификаторы сеанса с отслеживанием состояния должны быть аннулированы на сервере после выхода из системы. Токены JWT без сохранения состояния должны быть недолговечными, чтобы минимизировать возможности для злоумышленника. Для более долговечных токенов JWT настоятельно рекомендуется следовать стандартам OAuth для отзыва доступа.

Список CWE

A02:2021 – Ошибки в организации шифрования

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

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

Минимальные действия:

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

• Не храните конфиденциальные данные без необходимости. Удалите их как можно скорее или используйте токенизацию, соответствующую стандарту PCI DSS, или даже усечение. Данные, которые не сохраняются, не могут быть украдены.

• Убедитесь, что все конфиденциальные данные зашифрованы.

• Убедитесь, что используются современные и надежные стандартные алгоритмы, протоколы и ключи; используйте надлежащее управление ключами.

• Шифруйте все передаваемые данные с помощью защищенных протоколов, таких как TLS, с шифрами прямой секретности (FS), приоритезацией шифрования сервером и параметрами безопасности. Применяйте шифрование с помощью директив, таких как HTTP Strict Transport Security (HSTS).

• Отключите кэширование ответов, содержащих конфиденциальные данные.

• Примените необходимые меры безопасности в соответствии с классификацией данных.

• Не используйте устаревшие протоколы, такие как FTP и SMTP, для передачи конфиденциальных данных.

• Храните пароли, используя надежные адаптивные и подсоленные функции хэширования с коэффициентом работы (коэффициентом задержки), такие как Argon2, scrypt, bcrypt или PBKDF2.

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

• Всегда используйте шифрование с проверкой подлинности, а не просто шифрование.

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

• Убедитесь, что криптографическая случайность используется там, где это уместно, и что она не была запущена предсказуемым образом или с низкой энтропией. Большинство современных API-интерфейсов не требуют, чтобы разработчик запускал CSPRNG для обеспечения безопасности.

• Избегайте устаревших криптографических функций и схем заполнения, таких как MD5, SHA1, PKCS № 1 версии 1.5.

  Самостоятельно проверьте эффективность конфигурации и настроек.

Список CWE

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

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

• Предоставленные пользователем данные не проверяются, не фильтруются и не очищаются приложением.

• Динамические запросы или непараметризованные вызовы без контекстно-зависимого экранирования используются непосредственно в интерпретаторе.

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

• Вредоносные данные используются напрямую или объединяются. Команда SQL or содержит структуру и вредоносные данные в динамических запросах, командах или хранимых процедурах.

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

Минимальные действия:

• Предпочтительным вариантом является использование безопасного API, который полностью исключает использование интерпретатора, предоставляет параметризованный интерфейс или переходит на инструменты объектно-реляционного отображения (ORM).
  Примечание: Даже при настройке параметров хранимые процедуры все равно могут внедрять SQL-инъекцию, если PL/SQL или T-SQL объединяют запросы и данные или выполняют враждебные данные с помощью EXECUTE IMMEDIATE или exec().
• Используйте надежную проверку ввода на стороне сервера. Это не является полной защитой, поскольку для многих приложений требуются специальные символы, такие как текстовые области или API для мобильных приложений.
• Для любых остаточных динамических запросов экранируйте специальные символы, используя специальный синтаксис escape для этого интерпретатора.
  Примечание: Структуры SQL, такие как имена таблиц, столбцов и т.д., не могут быть экранированы, и, следовательно, имена структур, предоставляемые пользователем, опасны. Это распространенная проблема в программном обеспечении для написания отчетов.

Список CWE

A04:2021 – Небезопасная архитектура ПО

Риски, связанные с недостатками дизайна и архитектуры. Желательно моделирование угроз, безопасные шаблоны проектирования и эталонные архитектуры. Необходим переход к предварительному кодированию, которое имеет решающее значение для принципов Secure by Design. 

Небезопасный дизайн - это широкая категория, представляющая различные слабые места, которые выражаются как “отсутствующий или неэффективный дизайн элементов управления”. Небезопасный дизайн не является источником всех остальных 10 основных категорий рисков. У недостатков проектирования и дефектами реализации разные первопричины и способы устранения. В защищенном проекте все еще могут быть дефекты реализации, приводящие к уязвимостям, которые могут быть использованы. Небезопасный дизайн не может быть исправлен с помощью идеальной реализации, поскольку по определению никогда не создавались необходимые средства контроля безопасности для защиты от конкретных атак. Одним из факторов, способствующих небезопасному проектированию, является отсутствие профилирования бизнес-рисков, присущих разрабатываемому программному обеспечению или системе, и, следовательно, неспособность определить, какой уровень безопасности требуется для проектирования.

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

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

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

Минимальные действия:

• Создайте и используйте безопасный жизненный цикл разработки вместе с профессионалами AppSec, которые помогут оценить и спроектировать средства управления безопасностью и конфиденциальностью

• Создайте и используйте библиотеку шаблонов безопасного проектирования или готовых к использованию компонентов

• Используйте моделирование угроз для критически важной аутентификации, контроля доступа, бизнес-логики и потоков ключей

• Интегрируйте язык безопасности и элементы управления в истории пользователей

• Интегрируйте проверки достоверности на каждом уровне вашего приложения (от внешнего интерфейса до серверной части).

• Напишите модульные и интеграционные тесты, чтобы убедиться, что все критические потоки устойчивы к модели угроз. Составьте сценарии использования и неправильного использования для каждого уровня вашего приложения.

• Разделите уровни на системные и сетевые в зависимости от потребностей в защите.

• Продуманно разделяйте клиентов на всех уровнях

• Ограничивайте потребление ресурсов пользователем или службой

Примеры CWE

A05:2021 – Неправильная настройка системы безопасности

Уязвимость может присутствовать, если:

• Отсутствие надлежащего усиления безопасности в какой-либо части стека приложений или неправильно настроенные разрешения для облачных служб.

• Включены или установлены ненужные функции (например, ненужные порты, службы, страницы, учетные записи или привилегии).

• Учетные записи по умолчанию и их пароли по-прежнему включены и не изменяются.

• Обработка ошибок выявляет следы стека или другие чрезмерно информативные сообщения об ошибках для пользователей.

• В обновленных системах новейшие функции безопасности отключены или настроены ненадежно.

• Параметры безопасности на серверах приложений, платформах приложений (например, Struts, Spring, ASP.NET), библиотеках, базах данных и т.д. не настроены на безопасные значения.

• Сервер не отправляет заголовки или директивы безопасности или для них не установлены безопасные значения.

• Программное обеспечение устарело или уязвимо (см. A06:2021 - Уязвимые и устаревшие компоненты).

Минимальные действия:

• Возможность быстро и просто развернуть другую среду, которая соответствующим образом заблокирована. Среды разработки, контроля качества и производства должны быть настроены одинаково, при этом в каждой среде должны использоваться разные учетные данные. Этот процесс должен быть автоматизирован, чтобы свести к минимуму усилия, необходимые для настройки новой безопасной среды.

• Минимальная платформа без каких-либо ненужных функций, компонентов, документации и образцов. Удалите или не устанавливайте неиспользуемые функции и платформы.

• Задача по проверке и обновлению конфигураций, соответствующих всем замечаниям по безопасности, обновлениям и патчам, в рамках процесса управления исправлениями (см. A06:2021 - Уязвимые и устаревшие компоненты). Проверьте разрешения облачного хранилища (например, разрешения пакета S3).

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

• Отправка клиентам директив безопасности, например заголовков безопасности.

• Автоматизированный процесс проверки эффективности конфигураций и настроек во всех средах.

Примеры CWE

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

Система уязвима, если:

• Если вы не знаете версии всех используемых вами компонентов (как клиентских, так и серверных). Это включает компоненты, которые вы используете непосредственно, а также вложенные зависимости.

• Если программное обеспечение уязвимо, не поддерживается или устарело. Это включает в себя операционную систему, сервер веб-приложений, систему управления базами данных (СУБД), приложения, API и все компоненты, среды выполнения и библиотеки.

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

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

• Если разработчики программного обеспечения не проверяют совместимость обновленных или пропатченных библиотек.

• Если вы не обеспечите безопасность конфигураций компонентов

Минимальные действия:

Должен существовать процесс управления исправлениями, позволяющий:

• Удалять неиспользуемые зависимости, ненужные функции, компоненты, файлы и документацию.
• Постоянно проводите инвентаризацию версий как клиентских, так и серверных компонентов (например, фреймворков, библиотек) и их зависимостей, используя такие инструменты, как versions, OWASP Dependency Check, retire.js и т.д. Постоянно отслеживайте уязвимости в компонентах, например, в таких источниках, как Common Vulnerability and Exposures (CVE) и National Vulnerability Database (NVD). Используйте инструменты анализа состава программного обеспечения для автоматизации процесса. Подпишитесь на уведомления по электронной почте об уязвимостях в системе безопасности, связанных с используемыми вами компонентами.
• Приобретайте компоненты только из официальных источников по защищенным ссылкам. Отдавайте предпочтение подписанным пакетам, чтобы снизить вероятность включения модифицированного вредоносного компонента (см. A08:2021 - Сбои целостности программного обеспечения и данных).
• Следите за библиотеками и компонентами, которые не поддерживаются или не содержат исправлений безопасности для более старых версий. Если установка исправлений невозможна, рассмотрите возможность развертывания виртуального исправления для мониторинга, обнаружения или защиты от обнаруженной проблемы.

Примеры CWE

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

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

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

Минимальные действия:

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

• Не развертывайте систему с учетными данными по умолчанию, особенно для пользователей с правами администратора.

• Реализуйте проверку слабых паролей, например, сравнивайте новые или измененные пароли со списком из 10 000 самых плохих паролей.

• Приведите правила использования длины, сложности и ротации паролей в соответствие с рекомендациями Национального института стандартов и технологий (NIST) 800-63b в отношении запоминаемых секретов или других современных политик использования паролей, основанных на фактических данных.

• Убедитесь, что регистрация, восстановление учетных данных и API-интерфейсы защищены от атак по перечислению учетных записей, используя одни и те же сообщения для всех результатов.

• Ограничьте или чаще откладывайте неудачные попытки входа в систему, но будьте осторожны, чтобы не создать сценарий отказа в обслуживании. Регистрируйте все сбои и предупреждайте администраторов при обнаружении подтасовки учетных данных, перебора или других атак.

• Используйте защищенный встроенный менеджер сеансов на стороне сервера, который генерирует новый случайный идентификатор сеанса с высокой энтропией после входа в систему. Идентификатор сеанса не должен содержаться в URL-адресе, надежно храниться и аннулироваться после выхода из системы, простоя и абсолютных тайм-аутов.

Список CWE

A08:2021 – Сбои в обеспечении целостности программного обеспечения и данных

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

Минимальные действия:

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

• Убедитесь, что библиотеки и зависимости, такие как npm или Maven, используют надежные хранилища. Если у вас более высокий уровень риска, рассмотрите возможность размещения внутреннего репозитория с проверенной репутацией.

• Убедитесь, что для проверки того, что компоненты не содержат известных уязвимостей, используется инструмент обеспечения безопасности цепочки поставок программного обеспечения, такой как OWASP Dependency Check или OWASP CycloneDX

• Убедитесь, что существует процесс проверки кода и изменений конфигурации, чтобы свести к минимуму вероятность того, что вредоносный код или конфигурация могут быть внедрены в конвейер вашего программного обеспечения.

• Убедитесь, что конвейер CI/CD имеет надлежащее разделение, конфигурацию и контроль доступа, чтобы обеспечить целостность кода, проходящего через процессы сборки и развертывания.

• Убедитесь, что неподписанные или незашифрованные сериализованные данные не отправляются ненадежным клиентам без какой-либо проверки целостности или цифровой подписи для обнаружения подделки или воспроизведения сериализованных данных

A09:2021 – Ведение журнала безопасности и мониторинг сбоев

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

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

Минимальные действия:

• Убедитесь, что все сбои при входе в систему, контроле доступа и проверке ввода данных на стороне сервера регистрируются в достаточном пользовательском контексте для выявления подозрительных или вредоносных учетных записей и сохраняются в течение достаточного времени для проведения отложенного судебного анализа.
• Убедитесь, что журналы создаются в формате, удобном для использования в решениях для управления журналами.
• Убедитесь, что данные журнала правильно закодированы, чтобы предотвратить внедрение или атаки на системы ведения журнала или мониторинга.
• Убедитесь, что в транзакциях с высокой стоимостью есть контрольный журнал с элементами контроля целостности, чтобы предотвратить подделку или удаление, например, добавление таблиц базы данных только для добавления или аналогичных операций.
• Команды DevSecOps должны наладить эффективный мониторинг и оповещение, чтобы выявлять подозрительные действия и оперативно реагировать на них.
• Разработайте или утвердите план реагирования на инциденты и восстановления, такой как план Национального института стандартов и технологий (NIST) 800-61r2 или более поздней версии.

A10:2021 – SSRF

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

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

Минимальные действия:

• Сетевой уровень
  • Сегментируйте функциональность удаленного доступа к ресурсам в отдельных сетях, чтобы уменьшить влияние SSRF
  • Примените политики брандмауэра “запрещать по умолчанию” или правила контроля доступа к сети, чтобы блокировать весь трафик интрасети, кроме существенного.
    Подсказки:
    ~ Установите права собственности и жизненный цикл для правил брандмауэра на основе приложений.
    ~ Регистрируйте все принятые и заблокированные сетевые потоки на брандмауэрах (см. A09:2021 - Ведение журнала безопасности и мониторинг сбоев).
• Прикладной уровень:
  • Очистите и подтвердите все входные данные, предоставленные клиентом
  • Примените схему URL-адресов, порт и пункт назначения с помощью списка разрешений с положительным значением
  • Не отправляйте клиентам необработанные ответы
  • Отключите перенаправления HTTP
  • Следите за согласованностью URL-адресов, чтобы избежать таких атак, как повторная привязка DNS и условия гонки “время проверки, время использования” (TOCTOU).
  • Не используйте для защиты от SSRF список запрещенных действий или регулярное выражение. У злоумышленников есть списки полезной нагрузки, инструменты и навыки для обхода списков запрещенных действий.
• Дополнительные меры:
  • Не используйте другие службы, связанные с безопасностью, в системах с открытым исходным кодом (например, OpenID). Контролируйте локальный трафик в этих системах (например, localhost).
  • Для интерфейсов с выделенными и управляемыми группами пользователей используйте сетевое шифрование (например, VPN) в независимых системах, чтобы учесть очень высокие требования к защите.

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).