Відсутність Content Security Policy залишає браузери без вказівок, яким скриптам та ресурсам довіряти. Ця прогалина наражає застосунок на міжсайтовий скриптинг (XSS), ін’єкції скриптів та іншу небажану поведінку третіх сторін. Ця стаття пояснює:
- Що означає ця проблема
- Чому вона важлива
- Практичні рекомендації для керівників із безпеки
Що таке Content Security Policy?
Content Security Policy – це заголовок відповіді HTTP, який вказує браузерам, які скрипти, стилі, фрейми та інші ресурси можуть завантажуватися на сторінці. Обмежуючи те, що дозволяється виконувати, CSP знижує ризик міжсайтового скриптингу (XSS) та ін’єкції коду, особливо в сучасних середовищах, переповнених стороннім кодом.
Надійна CSP діє як запобіжник для поведінки під час виконання. Навіть якщо зловмисник знайде точку ін’єкції, обмежувальна політика може зупинити виконання його корисного навантаження.
Що означає «CSP header not set»?
Якщо ваш застосунок не надсилає заголовок Content-Security-Policy, браузер не має інформації про обмеження джерел контенту, які потрібно застосувати. Усі вбудовані скрипти, зовнішні скрипти та фрейми розглядаються як дозволені, якщо їх не заблоковано якимось іншим механізмом. З точки зору безпеки, робота такого застосунку рівнозначна водінню без ременів безпеки.
Ризики відсутності CSP
Без примусового застосування CSP зловмисник отримує більше свободи для впровадження ненадійних скриптів за допомогою відображеного (reflected), збереженого (stored) або DOM-орієнтованого XSS. Це може призвести до перехоплення сесій, появи фішингових оверлеїв, ексфільтрації даних або втручання в чинний контент сторінки. Сторонні скрипти, які завантажуються з рекламних мереж, інструментів аналітики або віджетів, також стають поверхнею підвищеного ризику, оскільки їх можуть замінити на шкідливі версії ще на рівні їхнього джерела.
CSP також може допомогти обмежити використання фреймів та пом’якшити наслідки клікджекінгу (clickjacking) у поєднанні з директивою frame-ancestors. Хоча це не є повноцінною заміною X-Frame-Options, сучасні розгортання часто покладаються на CSP як на основний рівень захисту. Реальні інциденти часто пов’язані з ненадійними скриптами, впровадженими у скомпрометовані бібліотеки або рекламні канали. Без CSP ці атаки виконуються непомітно і можуть тривати, поки їх не виявлять іншими способами.
Як виявити відсутні заголовки CSP
Динамічне тестування безпеки застосунків (DAST) є найнадійнішим способом виявляти відсутні або неефективні заголовки безпеки в масштабі, оскільки воно спостерігає за запущеним застосунком. Сучасна платформа безпеки застосунків може перевірити кожну доступну сторінку та виявити непослідовну поведінку заголовків або місця, де CSP не було застосовано. У середовищах CI/CD перевірка заголовків допомагає виявити регресії до їхнього релізу, тоді як інструменти розробника у браузері забезпечують швидку ручну перевірку. Якщо застосунок містить вразливості XSS, DAST зі скануванням на основі доказів додатково перевіряє, чи можна їх використати, і чи вплинула б CSP на можливість їх експлуатації.
Де налаштовувати заголовки CSP
Політики безпеки контенту можна налаштовувати на кількох різних рівнях:
- Конфігурація вебсервера
- Фреймворк застосунку
- Окремі відповіді застосунку (в заголовках або HTML)
Конфігурація на рівні сервера є найнадійнішим підходом у більшості випадків, оскільки вона гарантує, що кожна відповідь містить заголовок CSP, незалежно від того, яка частина застосунку її генерує. Це допомагає уникнути прогалин, спричинених різницею в маршрутизації або застарілими кінцевими точками, які працюють поза основним фреймворком, а також значно полегшує централізоване обслуговування.
Генерація заголовка CSP на рівні застосунку пропонує більше гнучкості, коли потрібні динамічні значення nonce, специфічні для маршруту директиви або програмний контроль над складною логікою рендерингу. Для особливих випадків або вузьконаправленого тестування слід застосувати обмежений набір директив CSP, використовуючи метатеги в самому HTML, хоча це менш безпечно, оскільки починає діяти лише після початку завантаження сторінки.
На практиці більшість організацій використовують комбінацію політик на рівні сервера для широкого охоплення та політик на рівні фреймворку там, де необхідні динамічна поведінка або детальний контроль. Заголовки CSP, а не метатеги, слід використовувати скрізь, де це можливо.
Використання режиму Content-Security-Policy-Report-Only
Режим лише для звітів (report-only) дозволяє виявляти порушення політики без блокування функціональності. Для цього використовується окремий заголовок Content-Security-Policy-Report-Only, який приймає значення, ідентичні фактичному заголовку CSP, але лише повідомляє про порушення політики замість блокування контенту. Ці два заголовки можна комбінувати (надсилати разом), якщо є бажання протестувати якусь нову директиву, продовжуючи примусове застосування наявної політики.
Під час етапу тестування очікувану поведінку можна порівнювати з фактичними порушеннями та коригувати директиви до моменту їхнього остаточного впровадження у продакшні.
Перевірка порушень CSP у браузері
Сучасні браузери фіксують проблеми з CSP у консолі розробника. Перегляд цих повідомлень дає розуміння того, які скрипти, фрейми та з’єднання потребують явних дозволів.
Валідація за допомогою автоматизованих інструментів
Інструменти, такі як CSP Evaluator від Google, допомагають виявляти слабкі директиви, надмірно широкі дозволи або небезпечні патерни. Вони корисні на ранніх етапах розгортання, особливо коли політики стають складними.
Найкращі практики довгострокового управління CSP
- Використання значень nonce або хешів для кращого контролю над вбудованими скриптами, особливо коли фреймворки рендерять динамічний контент.
- Уникнення або мінімізація використання символів підстановки (wildcards) задля зниження ризику ненавмисного надання дозволу ненадійним ресурсам.
- Підтримання списку надійних джерел, щоб політики залишалися синхронізованими зі змінами в застосунку.
- Застосування Subresource Integrity (SRI) для забезпечення додаткового рівня захисту зовнішніх скриптів.
- Проведення періодичних аудитів для перевірки узгодженості політики як з реальною поведінкою застосунку, так і з вимогами безпеки.
Вплив виправлення помилок CSP на бізнес та дотримання нормативних вимог
Добре реалізована CSP може значно знизити можливість експлуатації багатьох векторів XSS. Вона також підтримує вимоги до контролю в таких стандартах, як PCI DSS, SOC 2, HIPAA та ISO 27001. Уникнення компрометації на основі скриптів знижує витрати на реагування на інциденти, особливо для застосунків, орієнтованих на клієнта, які обробляють конфіденційні дані.
Як Invicti допомагає виправляти та запобігати помилкам CSP
Сканер DAST Invicti дозволяє легко виявляти відсутні або непослідовні заголовки CSP у рамках регулярного сканування, тому не потрібно покладатися на ручні перевірки в різних середовищах. Оскільки сканер тестує фактично запущений застосунок, а не вихідний код, він показує, де заголовки відсутні, перевизначені або застосовані лише на певних маршрутах, допомагаючи відстежувати відхилення в конфігурації та прогалини, які важко помітити лише з коду.
Коли сканування виявляє проблеми з XSS, сканування на основі доказів від Invicti зазвичай підтверджує, чи можна їх експлуатувати, і часто також надає підтвердження концепції (proof of concept) в один клік, яке відтворює проблему. Це дає чіткіше уявлення про те, де CSP може мати найбільший вплив і які знахідки вимагають негайної уваги.
Для команд, які працюють у кількох середовищах, платформа Invicti також допомагає виявляти використання сторонніх скриптів та кінцевих точок API, що можуть вплинути на рішення щодо CSP. Розробники отримують практичні результати, які вписуються в наявні робочі процеси, що дозволяє легше розставляти пріоритети для виправлень CSP та перевіряти їх, не уповільнюючи цикли релізу.
Перетворення CSP із джерела помилок на надійний засіб захисту
CSP є одним із найдієвіших заголовків безпеки для розгортання, оскільки він забезпечує миттєвий захист від поширених атак на основі скриптів. Після виправлення відсутнього заголовка, або ж такого, що надає надмірні дозволи, та точного налаштування політики, CSP можна включити до ширших заходів із посилення безпеки, які підвищують стійкість із відносно низькими накладними витратами. Автоматизоване сканування, послідовне примусове застосування та чітко визначене управління допомагають гарантувати, що CSP залишатиметься надійним рівнем захисту в міру розвитку застосунків.
Практичні рекомендації для керівників із безпеки
- Включення CSP до базових вимог безпеки застосунків.
- Використання автоматизованого сканування для регулярної перевірки на відсутність або непослідовність CSP та інших заголовків безпеки.
- Примусове застосування CSP на етапі CI/CD для запобігання регресіям.
- Використання режиму лише для звітів під час розгортання та внесення змін, щоб уникнути порушення функціональності.
- Навчання розробників правильному налаштуванню заголовків та безпечним патернам.
- Використання підтверджених результатів перевірки вразливостей для пріоритезації виправлень, пов’язаних із CSP.
