OWASP TOP 10

Проект 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 – ~~Cryptographic~~Ошибки ~~Failures~~в организации шифрования

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

Передаются ли какие-либо данные открытым текстом? Это касается таких протоколов, как 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 – Инъекции