Хедъри за сигурност на фронтенда: Овладяване на Content Security Policy (CSP)

В днешния дигитален свят, където уеб приложенията стават все по-сложни и взаимосвързани, защитата срещу заплахи за сигурността е от първостепенно значение. Докато на сигурността на бекенда често се обръща значително внимание, сигурността на фронтенда е също толкова важна. Хедърите за сигурност на фронтенда действат като първа линия на защита, предоставяйки механизъм за инструктиране на браузъра как да се държи и да защитава потребителите от различни атаки. Сред тези хедъри Content Security Policy (CSP) се откроява като мощен инструмент за смекчаване на широк спектър от рискове.

Какво представляват хедърите за сигурност на фронтенда?

Хедърите за сигурност на фронтенда са HTTP хедъри за отговор, които уеб сървърът изпраща на браузъра. Тези хедъри съдържат инструкции как браузърът трябва да обработва съдържанието, което получава. Те помагат за предотвратяване на често срещани атаки като:

• Cross-Site Scripting (XSS): Инжектиране на злонамерени скриптове в доверени уебсайтове.
• Clickjacking: Подлъгване на потребителите да кликнат върху нещо различно от това, което възприемат.
• Man-in-the-Middle Attacks: Прихващане на комуникацията между потребителя и сървъра.

Някои от най-важните хедъри за сигурност на фронтенда включват:

• Content Security Policy (CSP): Дефинира източниците, от които браузърът има право да зарежда ресурси.
• Strict-Transport-Security (HSTS): Принуждава браузъра да използва HTTPS за цялата комуникация с уебсайта.
• X-Frame-Options: Предотвратява вграждането на уебсайта в iframe, смекчавайки атаките тип „кликджекинг“.
• X-XSS-Protection: Активира вградения в браузъра XSS филтър. (Забележка: Често се заменя от CSP, но все още може да осигури ниво на защита).
• Referrer-Policy: Контролира количеството информация за реферер, изпращана със заявките.
• Feature-Policy (now Permissions-Policy): Позволява на разработчиците избирателно да активират и деактивират функции и API на браузъра.

По-задълбочен поглед върху Content Security Policy (CSP)

Content Security Policy (CSP) е HTTP хедър за отговор, който контролира ресурсите, които потребителският агент има право да зарежда за дадена страница. По същество той създава „бял списък“ с източници на одобрено съдържание, което значително намалява риска от XSS атаки. Чрез изричното дефиниране на произходите, от които могат да се зареждат ресурси като скриптове, стилове, изображения и шрифтове, CSP прави много по-трудно за нападателите да инжектират злонамерен код във вашия уебсайт.

Как работи CSP

CSP работи, като предоставя на браузъра списък с одобрени източници за различни типове съдържание. Когато браузърът срещне ресурс, който нарушава CSP, той блокира ресурса и докладва нарушението. Този механизъм за блокиране предотвратява изпълнението на злонамерен код, дори ако нападател успее да го инжектира в HTML.

CSP директиви

CSP директивите са основните компоненти на една CSP политика. Те указват разрешените източници за различни типове ресурси. Някои от най-често използваните директиви включват:

• default-src: Задава източника по подразбиране за всички типове ресурси. Това е резервна директива, която се прилага, когато не са дефинирани други, по-специфични директиви.
• script-src: Указва разрешените източници за JavaScript.
• style-src: Указва разрешените източници за CSS стилове.
• img-src: Указва разрешените източници за изображения.
• font-src: Указва разрешените източници за шрифтове.
• media-src: Указва разрешените източници за аудио и видео.
• object-src: Указва разрешените източници за плъгини като Flash. (Като цяло е най-добре да се избягва разрешаването на плъгини, ако е възможно).
• frame-src: Указва разрешените източници за фреймове (iframes).
• connect-src: Указва разрешените източници за мрежови заявки (AJAX, WebSockets).
• base-uri: Ограничава URL адресите, които могат да се използват в елемент <base>.
• form-action: Ограничава URL адресите, към които могат да се изпращат формуляри.
• frame-ancestors: Указва валидни „родители“, които могат да вградят страница, използвайки <frame>, <iframe>, <object>, <embed>, или <applet>. Тази директива осигурява защита срещу кликджекинг.
• upgrade-insecure-requests: Инструктира потребителските агенти да третират всички несигурни URL адреси на сайта (заредени през HTTP) така, сякаш са заменени със сигурни URL адреси (заредени през HTTPS). Тази директива е предназначена за уебсайтове, които са в процес на миграция от HTTP към HTTPS.
• report-uri: Указва URL адрес, на който браузърът трябва да изпраща доклади за нарушения на CSP. Остаряла в полза на `report-to`.
• report-to: Указва име на група, дефинирано в хедър `Report-To`. Това позволява по-фино управление на докладването, включително указване на множество крайни точки за докладване.

Стойности на източниците в CSP

Стойностите на източниците дефинират произходите, от които е разрешено зареждането на ресурси. Някои често срещани стойности на източници включват:

• *: Позволява съдържание от всякакъв източник (Избягвайте да използвате това в продукционна среда!).
• 'self': Позволява съдържание от същия произход (схема, хост и порт) като защитения документ.
• 'none': Забранява съдържание от всякакъв източник.
• 'unsafe-inline': Позволява използването на вграден (inline) JavaScript и CSS (Избягвайте да използвате това в продукционна среда!).
• 'unsafe-eval': Позволява използването на динамична оценка на код (напр. eval(), Function()) (Избягвайте да използвате това в продукционна среда!).
• 'strict-dynamic': Указва, че доверието, изрично дадено на скрипт, присъстващ в кода, като го придружава с nonce или хеш, трябва да се разпространи към всички скриптове, заредени от този предшественик.
• 'unsafe-hashes': Позволява специфични вградени (inline) обработчици на събития. Това обикновено не се препоръчва поради своята сложност и ограничена полза.
• data:: Позволява зареждане на ресурси от data URL адреси (напр. вградени изображения). Използвайте с повишено внимание.
• mediastream:: Позволява използването на `mediastream:` URIs като източник на медия.
• blob:: Позволява използването на `blob:` URI като източник на медия.
• filesystem:: Позволява зареждането на ресурси от файлова система.
• https://example.com: Позволява съдържание от конкретен домейн и порт.
• *.example.com: Позволява съдържание от всеки поддомейн на example.com.
• nonce-{random-value}: Позволява скриптове или стилове със съответстващ nonce атрибут. Това изисква генериране на случайна nonce стойност на сървъра за всяка заявка.
• sha256-{hash-value}: Позволява скриптове или стилове със съответстващ SHA256, SHA384 или SHA512 хеш.

Режими на CSP: Принудителен срещу „Само докладване“

CSP може да бъде внедрен в два режима:

• Принудителен режим (Enforce Mode): В този режим браузърът блокира всички ресурси, които нарушават CSP. Това е препоръчителният режим за продукционна среда. CSP се изпраща с помощта на хедъра `Content-Security-Policy`.
• Режим „Само докладване“ (Report-Only Mode): В този режим браузърът докладва нарушенията на CSP, но не блокира ресурсите. Това е полезно за тестване и оценка на CSP преди прилагането му. CSP се изпраща с помощта на хедъра `Content-Security-Policy-Report-Only`.

Внедряване на CSP: Ръководство стъпка по стъпка

Внедряването на CSP може да изглежда обезсърчително, но като следвате структуриран подход, можете ефективно да защитите вашето уеб приложение.

1. Започнете с политика в режим „Само докладване“

Започнете с внедряване на CSP в режим „само докладване“. Това ви позволява да наблюдавате нарушенията, без да нарушавате функционалността на уебсайта си. Конфигурирайте директивата report-uri или report-to, за да изпращате доклади за нарушения до определена крайна точка.

Примерен хедър (Report-Only): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. Анализирайте докладите за нарушения

Внимателно анализирайте докладите за нарушения, за да идентифицирате кои ресурси се блокират и защо. Това ще ви помогне да разберете зависимостите на ресурсите на вашия уебсайт и да идентифицирате потенциални уязвимости в сигурността.

Докладите за нарушения обикновено се изпращат като JSON данни до конфигурираната крайна точка report-uri или report-to. Тези доклади съдържат информация за нарушението, като например блокирания URI, нарушената директива и URI на документа.

3. Усъвършенствайте CSP политиката

Въз основа на докладите за нарушения, усъвършенствайте своята CSP политика, за да разрешите легитимни ресурси, като същевременно поддържате силна позиция по отношение на сигурността. Добавете конкретни стойности на източници за ресурсите, които се блокират. Обмислете използването на nonce или хешове за вградени скриптове и стилове, за да избегнете използването на 'unsafe-inline'.

4. Преминете към принудителен режим

След като сте уверени, че вашата CSP политика не блокира легитимни ресурси, преминете към принудителен режим. Това ще блокира всички останали нарушения и ще осигури надежден слой защита срещу XSS атаки.

Примерен хедър (Enforce): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. Наблюдавайте и поддържайте CSP политиката

CSP не е решение от типа „настрой и забрави“. От съществено значение е непрекъснато да наблюдавате вашата CSP политика и да я актуализирате, докато уебсайтът ви се развива и се появяват нови заплахи за сигурността. Редовно преглеждайте докладите за нарушения и коригирайте политиката при необходимост.

Практически примери за CSP

Нека разгледаме няколко практически примера за CSP за различни сценарии:

Пример 1: Основен CSP за прост уебсайт

Този CSP позволява съдържание от същия произход и разрешава изображения от всякакъв източник.

Content-Security-Policy: default-src 'self'; img-src *

Пример 2: CSP със специфични източници за скриптове и стилове

Този CSP позволява скриптове от същия произход и от конкретен CDN, както и стилове от същия произход и вградени стилове.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

Пример 3: CSP с Nonce за вградени скриптове

Този CSP изисква уникален nonce за всеки вграден скрипт.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

Важно: Стойността на nonce трябва да се генерира динамично на сървъра за всяка заявка. Това предотвратява повторното използване на nonce от нападатели.

Пример 4: CSP, ограничаващ frame-ancestors за предотвратяване на кликджекинг

Този CSP предотвратява вграждането на страницата в iframe на всеки домейн, с изключение на `https://example.com`.

Content-Security-Policy: frame-ancestors 'self' https://example.com

Пример 5: По-ограничаващ CSP, използващ 'strict-dynamic' и резервен вариант 'self'

Този CSP използва `strict-dynamic` за съвременни браузъри, като същевременно поддържа и по-стари браузъри, които не го поддържат. Той също така включва `report-uri` за наблюдение на нарушенията.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Не забравяйте да замените `{random-nonce}` с динамично генерирана nonce стойност от страна на сървъра.

CSP и едностранични приложения (SPAs)

Внедряването на CSP в SPA може да бъде предизвикателство поради динамичния характер на тези приложения. SPAs често разчитат в голяма степен на JavaScript за генериране и манипулиране на DOM, което може да доведе до нарушения на CSP, ако не се подходи внимателно.

Ето няколко съвета за внедряване на CSP в SPA:

• Избягвайте 'unsafe-inline' и 'unsafe-eval': Тези директиви трябва да се избягват, когато е възможно, в SPA. Те значително отслабват сигурността на вашето приложение.
• Използвайте Nonce или хешове: Използвайте nonce или хешове за вградени скриптове и стилове. Това е препоръчителният подход за SPA.
• Обмислете Trusted Types: Trusted Types е API на браузъра, което помага за предотвратяване на DOM-базирани XSS уязвимости. Може да се използва в комбинация с CSP за допълнително повишаване на сигурността.
• Използвайте рамка, съвместима с CSP: Някои фронтенд рамки (като React със специфични конфигурации, Angular и Vue.js) предоставят функции, които ви помагат да внедрите CSP по-лесно.

Други важни хедъри за сигурност на фронтенда

Докато CSP е крайъгълен камък на сигурността на фронтенда, други хедъри играят решаваща роля в осигуряването на цялостна стратегия за защита:

Strict-Transport-Security (HSTS)

Хедърът Strict-Transport-Security (HSTS) инструктира браузъра винаги да използва HTTPS за свързване с уебсайта. Това предотвратява атаки тип „man-in-the-middle“, които се опитват да понижат нивото на връзката до HTTP.

Примерен хедър: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: Указва продължителността (в секунди), за която браузърът трябва да помни да достъпва сайта само през HTTPS. Стойност от 31536000 секунди (1 година) се препоръчва за продукционни среди.
• includeSubDomains: Указва, че HSTS политиката се прилага за всички поддомейни на домейна.
• preload: Позволява домейнът да бъде включен в списък с домейни с активиран HSTS, който се зарежда предварително в браузърите. Това изисква да изпратите домейна си в списъка за предварително зареждане на HSTS, поддържан от Google.

X-Frame-Options

Хедърът X-Frame-Options предотвратява атаки тип „кликджекинг“, като контролира дали уебсайтът може да бъде вграден в iframe.

Примерен хедър: X-Frame-Options: DENY

Възможни стойности:

• DENY: Предотвратява показването на страницата в iframe, независимо от произхода.
• SAMEORIGIN: Позволява страницата да се показва в iframe само ако произходът на iframe съвпада с произхода на страницата.
• ALLOW-FROM uri: Позволява страницата да се показва в iframe само ако произходът на iframe съвпада с посочения URI. Забележка: Тази опция е остаряла и може да не се поддържа от всички браузъри.

Забележка: Директивата frame-ancestors в CSP предоставя по-гъвкав и мощен начин за контрол на рамкирането и като цяло се предпочита пред X-Frame-Options.

X-XSS-Protection

Хедърът X-XSS-Protection активира вградения в браузъра XSS филтър. Докато CSP е по-надеждно решение за предотвратяване на XSS атаки, този хедър може да осигури допълнителен слой защита, особено за по-стари браузъри, които може да не поддържат напълно CSP.

Примерен хедър: X-XSS-Protection: 1; mode=block

• 1: Активира XSS филтъра.
• 0: Деактивира XSS филтъра.
• mode=block: Инструктира браузъра да блокира страницата, ако бъде открита XSS атака.
• report=uri: Указва URL адрес, на който браузърът трябва да изпрати доклад, ако бъде открита XSS атака.

Referrer-Policy

Хедърът Referrer-Policy контролира количеството информация за реферер, която се изпраща със заявките. Информацията за реферер може да се използва за проследяване на потребители в различни уебсайтове, така че контролирането ѝ може да подобри поверителността на потребителите.

Примерен хедър: Referrer-Policy: strict-origin-when-cross-origin

Някои често срещани стойности:

• no-referrer: Никога не изпраща хедъра Referer.
• no-referrer-when-downgrade: Не изпраща хедъра Referer към произходи без TLS (HTTPS).
• origin: Изпраща само произхода (схема, хост и порт) в хедъра Referer.
• origin-when-cross-origin: Изпраща произхода за заявки към друг произход и пълния URL за заявки към същия произход.
• same-origin: Изпраща хедъра Referer за заявки към същия произход, но не и за заявки към друг произход.
• strict-origin: Изпраща само произхода, когато нивото на сигурност на протокола остава същото (HTTPS към HTTPS), но не изпраща хедър към по-малко сигурна дестинация (HTTPS към HTTP).
• strict-origin-when-cross-origin: Изпраща произхода при извършване на заявка към същия произход. За заявки към друг произход изпраща произхода само когато нивото на сигурност на протокола остава същото (HTTPS към HTTPS), но не изпраща хедър към по-малко сигурна дестинация (HTTPS към HTTP).
• unsafe-url: Изпраща пълния URL в хедъра Referer, независимо от произхода. Използвайте с изключително внимание, тъй като това може да разкрие чувствителна информация.

Permissions-Policy (formerly Feature-Policy)

Хедърът Permissions-Policy (преди известен като Feature-Policy) позволява на разработчиците избирателно да активират и деактивират функции и API на браузъра. Това може да помогне за намаляване на повърхността за атака на вашето приложение и да подобри поверителността на потребителите.

Примерен хедър: Permissions-Policy: geolocation=()

Този пример деактивира API за геолокация за уебсайта.

Други функции, които могат да се контролират с Permissions-Policy, включват:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

Настройване на хедъри за сигурност на различни платформи

Методът за задаване на хедъри за сигурност варира в зависимост от уеб сървъра или платформата, която използвате. Ето някои често срещани примери:

Apache

Можете да зададете хедъри за сигурност в Apache, като ги добавите към файла .htaccess или към конфигурационния файл на сървъра (httpd.conf).

Примерна конфигурация за .htaccess:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Можете да зададете хедъри за сигурност в Nginx, като ги добавите към сървърния блок в конфигурационния файл на Nginx (nginx.conf).

Примерна конфигурация за Nginx:

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

Можете да зададете хедъри за сигурност в Node.js, използвайки мидълуер като Helmet.

Пример с използване на Helmet:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// Customize CSP if needed
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

Cloudflare ви позволява да задавате хедъри за сигурност, използвайки техните Page Rules или Transform Rules.

Тестване на вашите хедъри за сигурност

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

• SecurityHeaders.com: Прост и ефективен инструмент за анализ на хедъри за сигурност.
• Mozilla Observatory: Цялостен инструмент за тестване на сигурността на уебсайтове, включително хедъри за сигурност.
• WebPageTest.org: Позволява ви да видите HTTP хедърите в диаграмата тип „водопад“ (waterfall chart).

Заключение

Хедърите за сигурност на фронтенда, особено Content Security Policy (CSP), са от съществено значение за защитата на уеб приложенията от различни атаки и за повишаване на сигурността на потребителите. Чрез внимателно внедряване и поддържане на тези хедъри можете значително да намалите риска от XSS, кликджекинг и други уязвимости в сигурността. Не забравяйте да започнете с политика в режим „само докладване“, да анализирате докладите за нарушения, да усъвършенствате политиката и след това да преминете към принудителен режим. Редовно наблюдавайте и актуализирайте вашите хедъри за сигурност, за да поддържате уебсайта си защитен, докато той се развива и се появяват нови заплахи.

Като възприемете проактивен подход към сигурността на фронтенда, можете да изградите по-сигурни и надеждни уеб приложения, които защитават вашите потребители и вашия бизнес.