Проблемы безопасности
Дата обновления перевода 2022-08-25
Проблемы безопасности
Этот документ объясняет, как базовая команда Symfony справляется с проблемами
безопасности (Symfony - это код, находящийся в главном хранилище Git)
symfony/symfony
.
Сообщение о проблеме безопасности
Если вы считаете, что нашли проблему безопасности в Symfony, не используйте трекер багов и не публикуйте её публично. Вместо этого все проблемы безопасности должны направляться по адресу security [at] symfony.com. Письма, отправленные на этот адрес, пересылаются по закрытому списку рассылки основной команды Symfony.
Следующие проблемы не считаются проблемами безопасности и должны рассматриваться как обычные исправления багов (если у вас есть какие-либо сомнения, не стесняйтесь отправить нам письмо для подтверждения):
- Любые проблемы безопасности, обнаруженные в инструментах отладки, которые никогда
не должны быть включены в производстве (включая веб-профилировщик или что-либо, включённое,
когда
APP_DEBUG
установлен какtrue
илиAPP_ENV
установлен в любое значение, кромеprod
); - Любые проблемы безопасности, обнаруженные в классах, предоставленных для тестирования,
которые не должны в производстве (например, имитационные классы, содержащие
Mock
в своём имени или классы в пространстве имёнTest
); - Любые исправления, которые могут быть классифицированы как усиление безопасности, например, перечисление маршрутов, обход блокировки входа в систему, атаки типа "отказ в обслуживании", атаки по времени или отсутствие атрибутов ``SensitiveParameter''.
В любом случае, окончательное решение о том, какие проблемы считаются уязвимостями, остаётся за основной командой.
Награды за баги в безопасности
Symfony - проект с открытым исходным кодом, в котором большую часть работы выполняют добровольцы. Мы ценим то, что разработчики пытаются найти проблемы безопасности в Symfony и ответственно сообщают о них, но в настоящее время мы не можем выплачивать вознаграждения за баги.
Процесс решения
С каждым заявлением, мы вначаел пытаемся подтвердить уязвимость. Когда она подтверждена, базовая команда начинает работу над решением, следуя этим шагам:
- Отправка признательности отправителю;
- Работа над патчем;
- Получение CVE-идентификатора с mitre.org;
Написание объявления безопасности об уязвимости для официального блога Symfony. Этот пост должен содержать следующую информацию:
- заголовок, всегда включающий в себя строку "Релиз безопасности";
- описание уязвимости;
- затронутые версии;
- возможное использование;
- как запатчить, обновить или обойти затронутые приложения;
- CVE-идентификатор;
- благодарности.
- Отправка патча и объявления отправителю для отзыва;
- Применение патча ко всем поддерживаемым версиям Symfony;
- Запаковать новые версии для всех затронутых версий;
- Публикация поста в официальном блоге Symfony (он также должен быть добавлен в категорию "`Консультация по вопросам безопасности`_");
- Обновить список консультантов безопасности (см. ниже);
- Обновить публичную DB консультаций безопасности, содержающуюся организацией
FriendsOfPHP, которая используется командой
security:check
.
Note
Релизы, которые включают в себя проблемы безопасности, не должны выпускаться по выходным, кроме случаев, когда об уязвимости заявили публично.
Note
Пока мы работаем над патчем, пожалуйста, не сообщайте о проблеме публично.
Note
Решение проблемы занимает от нескольких дней до месяца, в зависимости от сложности и координации с целевыми приложениями (см. следующий раздел).
Коллаборация с общедоступными целевыми проектами
Так как Symfony используется в основном в больших общедоступных проектах, мы стандартизировали то, как команда безопасности Symfony сотрудничает с целевыми проектами по вопросам безопасности. Этот процесс работает следующим образом:
- После того, как команда безопасности Symfony признала проблему безопасности, она немедленно отправляет письмо командам безопасности целевых проектов, чтобы проинформировать их о проблеме;
- Команда безопасности Symfony создаёт приватное хранилище Git, чтобы облегчить сотрудничество над проблемой и доступ к этому хранилищу предоставляется команде безопасности Symfony, вкладчикам Symfony, которых затронула проблема, и к одному представителю из каждого целевого проекта;
- Все люди с доступом к приватному хранилищу работают над решением, чтобы решить проблему через запросы вызова, обзоры кода и комментарии;
- Когда решение найдено, все затронутые проекты объединяются, чтобы выбрать лучшую дату общего релиза (нет гарантий, что все релизы будут в одно время, но мы очень стараемся выпускать их примерно одновременно). Когда неизвестно, что проблема эксплуатируется в "дикой жизни", период двух недель выглядит вполне разумно.
Список целевых проектов, участвующих в этом процессе держится максимально коротким, чтобы лучше справляться с потоком конфиденциальной информации до её оглашения. Поэтому проекты добавляются под полной секретностью со стороны команды безопасности Symfony.
Сегодня, следующие проекты валидировали этот процесс и являются частью целевых проектов, включённых в этот процесс:
- Drupal (релизы обычно происходят по средам)
- eZPublish
Серьёзность проблемы
Для определения степени серьёзности проблемы безопасности мы принимаем во внимание сложность потенциальной атаки, влияние уязвимости, а также количество проектов, которые она может затронуть. Полученная оценка из 15 баллов затем преобразуется в уровень: Низкий, Средний, Высокий, Критический или Исключительный.
Сложность атаки
Оценка от 1 до 5 в зависимости от сложности эксплуатации уязвимости
- 4 - 5 Базовый: злоумышленник должен выполнить ряд простых действий
- 2 - 3 Сложный: злоумышленник должен выполнить неинтуитивные действия с высоким уровнем зависимостей
- 1 - 2 Высокая: Успешная атака зависит от условий, не зависящих от контроля злоумышленника. То есть успешная атака не может быть осуществлена произвольно, а требует от злоумышленника вложения определённых усилий по подготовке или проведению атаки на уязвимый компонент, прежде чем атака будет успешной.
Влияние
Баллы по следующим направлениям суммируются для получения оценки. Оценка влияния имеет 6 баллов. Каждая область оценивается от 0 до 4 баллов.
- Целостность: Приводит ли данная уязвимость к доступу к непубличным данным? Если да, то имеет ли злоумышленник контроль над раскрытыми данными? (0-4)
- Раскрытие: Может ли данная уязвимость позволить скомпрометировать системные данные (или данные, обрабатываемые системой)? Если да, то имеет ли злоумышленник контроль над модификацией? (0-4)
- Выполнение кода: Позволяет ли уязвимость выполнить произвольный код в системе конечного пользователя или на сервере, на котором она работает? (0-4)
- Доступность: Затронута ли доступность сервиса или приложения? Является ли это снижением доступности или полной потерей доступности сервиса/приложения? Доступность включает в себя сетевые сервисы (например, базы данных) или источники, такие как потребление пропускной способности сети, циклов процессора или дисковое пространство. (0-4)
Затронутые проекты
*Баллы по следующим направлениям суммируются для получения оценки. Оценка для затронутых проектов ограничивается 4 баллами.
- Затронет ли это некоторых или всех, кто использует компонент? (1-2)
- Считается ли уже использование компонента, которое может привести к подобному, плохой практикой? (0-1)
- Насколько распространён/популярен компонент (например, Console vs HttpFoundation vs Lock)? (0-2)
- Затронут ли ряд известных проектов с открытым исходным кодом, использующих Symfony, что требует согласованных релизов? (0-1)
Итоговые баллы
- Сложность атаки: 1 - 5
- Влияние: 1 - 6
- Затронутые проекты: 1 - 4
Уровни серьёзности
- Низкий: 1 - 5
- Средний: 6 - 10
- Высокий: 11 - 12
- Критический: 13 - 14
- Исключительный: 15
Консультанты безопасности
Tip
Вы можете проверить ваше приложение Symfony на известные уязвимости безопасности,
используя команду security:check
(см. Как проверить на известные уязвимости защиты в ваших зависимостях).
Просмотрите категорию блога Security Advisories для получения списка всех уязвимостей безопасности, которые были устранены в релизах Symfony, начиная с версии Symfony 1.0.0.