Проблеми безпеки

Дата оновлення перекладу 2023-08-25

Проблеми безпеки

Цей документ пояснює, як питання безпеки Symfony вирішуються командою Symfony (Symfony - це код, розміщений у головному Git-репозиторії symfony/symfony).

Повідомлення про проблему безпеки

Якщо ви вважаєте, що знайшли проблему безпеки в Symfony, не використовуйте баг-трекер і не публікуйте її публічно. Замість цього, всі проблеми безпеки повинні бути надіслані на адресу security [at] symfony.com. Листи, надіслані на цю адресу, пересилаються за приватним списком розсилки основної команди Symfony.

Наступні проблеми не вважаються проблемами безпеки і повинні вирішуватися як звичайні виправлення багів (якщо у вас є якісь сумніви, не соромтеся надсилати нам електронного листа для підтвердження):

  • Будь-які проблеми з безпекою, виявлені в інструментах налагодження, які ніколи не повинні бути включені в виробництві (включаючи веб-профілювальник або будь-що, що вмикається, коли APP_DEBUG встановлено як true або APP_ENV встановлено у будь-яке значення, окрім prod);
  • Будь-які проблеми з безпекою, знайдені в класах, наданих для допомоги в тестуванні, які не повинні ніколи використовуватися у виробництві (як, наприклад, класи-імітації, які містять Mock у своєму імені або класи у просторі імен Test);
  • Будь-які виправлення, які можна класифікувати як посилення безпеки, такі як перерахування маршрутів, обхід дроселювання логіну, атаки на відмову в обслуговуванні, атаки на час або відсутність атрибутів SensitiveParameter.

У будь-якому випадку, основна команда приймає остаточне рішення про те, які проблеми вважати вразливостями безпеки.

Винагорода за баги безпеки

Symfony - це проект з відкритим вихідним кодом, де більша частина роботи виконується волонтерами. Ми цінуємо, що розробники намагаються знайти проблеми безпеки в Symfony і відповідально повідомляють про них, але наразі ми не можемо виплачувати винагороди за виправлення помилок.

Процес вирішення проблеми

Для кожного повідомлення ми спочатку намагаємося підтвердити вразливість. Коли вона підтверджується, основна команда працює над рішенням, виконуючи наступні кроки:

  1. Відправка повідомлення з підтвердженням заявнику;
  2. Робота над патчем;
  3. Отримаея ідентифікатора CVE з mitre.org;
  4. Написання повідомлення про вразливість в офіційному блозі Symfony. Цей пост повинен містити наступну інформацію:

    • заголовок, який завжди має містити рядок "реліз Безпеки";
    • опис вразливості;
    • уражені версії;
    • можливі експлойти;
    • як виправити/оновити/знайти обхідні шляхи для уражених програм;
    • ідентифікатор CVE;
    • вдячності.
  5. Відправка патчу та анонса заявнику для ознайомлення;
  6. Застосуваня патчу до всіх підтримуваних версій Symfony;
  7. Пакети нових версій для всіх постраждалих версій;
  8. Публікація посту в офіційному блозі Symfony (він також повинен бути доданий в категорію "`Повідомлення про безпеку`_");
  9. Оновлення публічної бази даних безпеки, яка ведеться організацією FriendsOfPHP і яка використовується командою check:security .

Note

Релізи, які містять проблеми з безпекою, не слід робити у суботу або неділю, за винятком випадків, коли вразливість було викладено у відкритий доступ.

Note

Поки ми працюємо над патчем, будь ласка, не повідомляйте про проблему публічно.

Note

Вирішення проблеми може зайняти від кількох днів до місяця, залежно від її складності та координації з наступними проектами (див. наступний параграф).

Співпраця з наступними проектами з відкритим вихідним кодом

Оскільки Symfony використовується багатьма великими проектами з відкритим вихідним кодом, ми стандартизували спосіб, в який команда безпеки Symfony співпрацює над питаннями безпеки з іншими проектами. Процес відбувається наступним чином:

  1. Після того, як команда безпеки Symfony виявила проблему безпеки, вона негайно надсилає імейл командам безпеки наступних проектів, щоб щоб повідомити їх про проблему;
  2. Команда безпеки Symfony створює приватний Git-репозиторій, щоб полегшити спільну роботу над проблемою, і доступ до цього репозиторію надається команді безпеки Symfony, учасникам Symfony, на яких впливає проблема, і одному представнику від кожного з наступних проектів;
  3. Всі люди з доступом до приватного репозиторію працюють над вирішенням проблеми за допомогою запитів на додавання, оглядів коду та коментарів;
  4. Після того, як виправлення знайдено, всі залучені проекти співпрацюють, щоб знайти найкращу дату для спільного релізу (немає гарантії, що всі релізи відбудуться одночасно, але ми будемо намагатися зробити їх приблизно в один і той самий час). Якщо невідомо, що проблема буде експлуатуватися, період у два тижні вважається розумним терміном.

Список наступних проектів, які беруть участь у цьому процесі, утримується якомога меншим наскільки це можливо, щоб краще керувати потоком конфіденційної інформації до її розкриття. Таким чином, проекти включаються на власний розсуд команди безпеки 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 на наявність відомих вразливостей безпеки за допомогою команди check:security .

Перевірте категорію блогу Повідомлення про безпеку для отримання списку всіх вразливостей безпеки, які було виправлено у випусках Symfony, починаючи з версії Symfony 1.0.0.