Хедъри за сигурност на уебсайтове: правилно задаване на Security Headers

Накратко: Хедърите за сигурност са указания на уеб сървъра към браузъра, които защитават посетителите от атаки като Cross-Site Scripting, clickjacking и нешифровани връзки. Най-важните са HSTS, Content Security Policy, X-Content-Type-Options, защита срещу чужди рамки, Referrer-Policy и Permissions-Policy. Те са разумно заздравяване, но не заместват актуализациите на сървъра.

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

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

За операторите е важна преценката: хедърите защитават на първо място посетителите, например от прихващане на сесии или от манипулирани формуляри. Те не затварят уязвимости на сървъра. Слабост в PHP, в CMS или в разширение остава, колкото и добре да са зададени хедърите. В съчетание с чист код обаче значително ограничават последствията от много грешки.

Най-важните хедъри за сигурност накратко

HSTS трябва да зададете едва когато всички поддомейни са надеждно достъпни през HTTPS. Браузърът запомня указанието за посочения период; грешка тогава не може да се върне веднага. При нужда започнете с кратък срок и го увеличете след успешни тестове. Допълнителната опция preload вписва домейна трайно в списъците на производителите на браузъри и трябва да се задава само след внимателна проверка.

Хедърите освен това не са единственото място, където браузърът предлага защита. Бисквитките трябва да носят атрибутите Secure, HttpOnly и SameSite, за да не се прихващат сесии през нешифровани връзки или чрез скриптове. Как да го настроите във PHP, описва наръчникът за сесиите.

Задаване на хедъри за сигурност в Nginx

В Nginx хедърите принадлежат в блока server на съответния уебсайт. Добавката always гарантира, че те се изпращат и при страници с грешки.

server {
    # ...
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'" always;

    server_tokens off;
}

Особеност на Nginx: ако блок location задава собствени инструкции add_header, хедърите от блока server там не се наследяват. Затова проверете и подстраниците и статичните файлове. Допълнително заздравяване за тази комбинация описва страницата Защита на Nginx с PHP-FPM.

Задаване на хедъри за сигурност в Apache

При Apache Ви е нужен модулът mod_headers. Инструкциите принадлежат във VirtualHost или, ако няма достъп до него, в .htaccess.

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

ServerTokens Prod
ServerSignature Off

ServerTokens и ServerSignature принадлежат в основната конфигурация. Те пречат на сървъра да посочва точната си версия в отговорите и страниците с грешки. В php.ini същото за PHP постигате с expose_php = Off.

Постепенно въвеждане на Content Security Policy

Content Security Policy е най-ефективният, но и най-взискателният хедър. Тя определя от кои източници могат да се зареждат скриптове, стилови листове, изображения, шрифтове и рамки. Ако внедрен скрипт се зареди от чужд домейн, браузърът го блокира.

Съвременните уебсайтове често вграждат инструменти за анализ, доставчици на плащания, картографски услуги или видеа. Прекалено строга политика тогава спира функции. Затова действайте на стъпки:

• Започнете първо с Content-Security-Policy-Report-Only. Браузърът съобщава нарушенията в конзолата за разработчици или на събирателен адрес, но не блокира нищо.
• Установете всички необходими източници и ги разрешете целенасочено, вместо да ползвате общи заместващи знаци.
• Постепенно изнесете inline скриптовете във файлове или ги снабдете с nonces, за да се откажете от 'unsafe-inline'.
• Едва след тестова фаза без неочаквани съобщения превключете към Content-Security-Policy.

Проверка на хедърите и избягване на типични грешки

След всяка промяна проверявайте дали хедърите действително достигат. Това става без допълнителни инструменти с curl:

# Тест на конфигурацията и презареждане
nginx -t && systemctl reload nginx

# Показване на хедърите на началната страница и на статичен файл
curl -sI https://www.example.de/ | grep -iE 'strict|content-security|x-content|x-frame|referrer|permissions|server'
curl -sI https://www.example.de/favicon.ico | grep -iE 'strict|x-content'

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

Определете затова едно място, където хедърите се поддържат, най-добре уеб сървърът или предходната услуга. Много разширения за CMS също предлагат настройки за хедъри за сигурност. Това е удобно, но лесно води до двойни или противоречиви данни, ако допълнително сървърът задава хедъри. За отделни тестове подхождат и инструментите за разработчици на браузъра: в раздела Network виждате за всяка заявка хедърите на отговора, а конзолата показва нарушенията на Content Security Policy.

Как конкретно помага PHP SOS?

• Проверяваме актуалните хедъри на всички Ваши уебсайтове, включително зад CDN и прокси, и показваме пропуските и противоречията.
• Задаваме хедърите централно в уеб сървъра в рамките на заздравяването на сървъра и тестваме началната страница, подстраниците и страниците с грешки.
• Въвеждаме Content Security Policy в режим Report-Only, оценяваме съобщенията и я пускаме в действие след съгласуване.
• Където промени в кода не са възможни веднага, допълваме защитата с WAF правила и виртуално пачване.

Често задавани въпроси

Източници

• OWASP Cheat Sheet Series (HTTP Headers)
• OWASP Top 10
• BSI: Препоръки за уеб сървъри