Defaults.Exposed › Поправки › Content-Security-Policy (CSP)

Как да поправите Content-Security-Policy (CSP)

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

Заключение за вашия бизнес: Ако вашият сайт бъде манипулиран, злонамерен код може да чете данните за разплащателна карта и влизане на вашите клиенти директно от вашата каса, докато всичко изглежда напълно нормално — оставяйки ви с връщания на суми, претенции за измама, подлежащо на докладване нарушение на данни и неуспех в проверка, използван от IT екипите на по-голями клиенти за забавяне или провал на сделка.

Какво може да ви струва това

Скрит код се промъква в една от страниците ви и тихо копира всеки номер на карта и парола, въвеждани от клиентите ви при плащане, изпращайки го на нападател, докато сайтът ви изглежда напълно нормален — разбирате само когато пристигнат жалбите за измама.
Измамник поставя фалшив формуляр 'платете тук' на вашия реален уебсайт, улавящ плащания в собствената му сметка; клиентите смятат, че са ви платили, обвиняват ви когато стоките не пристигнат и искат парите обратно.
IT екипът на по-голям клиент сканира вашия сайт, вижда, че тази основна защита е изключена и го маркира — спирайки или губейки ви договора, докато не можете да докажете, че е поправено.
Нарушение, проследено до липсваща стандартна защитна мярка, се превръща в подлежащ на докладване инцидент: регулаторни въпроси, известяване на клиенти и удар в репутацията, струващ много повече от безплатната поправка.

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

Какво е това, с прости думи

Когато някой посещава вашия уебсайт, браузърът им изтегля страницата ви и изпълнява всеки код на нея — скриптовете, правещи менютата да се отварят, бутоните да работят, формулярите за плащане да се изпращат и т.н. По подразбиране браузърът им се доверява на всичко. Той няма начин да знае кой код е наистина ваш и кой е промъкнат от някой друг.

Политиката за сигурност на съдържанието (CSP) е кратък списък с правила, прикрепен от вашия уебсайт към всяка страница, казващ на браузъра: „изпълнявайте само код от тези одобрени от мен източници и откажете всичко друго.” Разликата е между нощен клуб, пускащ всеки, и такъв с гостна листа на вратата.

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

Какво може да ви струва това

Това не е абстрактно. Атаката, която CSP предотвратява — код, инжектиран в страница, крадящ данни от вашите собствени клиенти — стои зад някои от най-големите нарушения на данни за карти. Ето как обикновено се разиграва за нормален бизнес:

Невидимият скимер при плащане. Нападател промъква няколко реда код на страницата ви за плащане чрез уязвим плъгин или компрометиран скрипт от трета страна. Всеки номер на карта, ниме и CVV, въвеждани от клиентите ви, се копира и изпраща в реално време на нападателя. Сайтът ви изглежда и работи перфектно; катинарът е там. Разбирате за него седмици по-късно, когато доставчикът ви на плащания се обади за клъстер от доклади за измама, всички проследяващи обратно до вашия магазин. Сега сте изправени пред връщания на суми, принудителен одит за сигурност, евентуална загуба на права за обработка на карти и нарушение, което може да е законово задължително да докладвате.
Фалшивият формуляр за плащане. Измамник инжектира убедителна кутия „платете тук” на вашия реален уебсайт. Клиентите въвеждат данните си, доверявайки се на вашата марка; парите и данните отиват при нападателя. Клиентите ви обвиняват — и не са погрешни, защото се е случило на вашия сайт.
Изгубеният договор. Екипът за сигурност на по-голям потенциален клиент прави автоматично сканиране на вашия сайт като part от дю дилиджънс на доставчика. Липсваща политика за сигурност на съдържанието се появява незабавно като пропаст с висока сериозност. За проверяващ за закупуване или сигурност, тази единствена липсваща защитна мярка се чете като „Този доставчик не спазва основите” — и сделката спира, докато те искат отстраняване на проблема или тихо отива при конкурент, преминал проверката.
Подлежащото на докладване нарушение. Когато нарушение на данни бъде проследено до липсваща, стандартна, безплатна защитна мярка, то спира да бъде лош късмет и започва да изглежда като небрежност. Това променя въпросите на регулатора, задължението за известяване на клиенти и разходите — и глобата, и репутационната щета, продължаваща дълго след затварянето на инцидента.
Компрометираната реклама или джаджа. Много сайтове зареждат код от външни страни — рекламни мрежи, шрифтове, чат за поддръжка, анализи. Ако кое да е от тях е нарушено, злонамереният код се вози директно на вашите страници. CSP ограничава щетите, позволявайки само конкретните externos източници, на които се доверявате, така че нарушението на един доставчик не се превръща автоматично в ваше.

Какво всъщност е (детайлите)

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

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

С прости думи казва: по подразбиране зареждайте само неща от собствения ми сайт; изпълнявайте скриптове само от собствения ми сайт; не разрешавайте стари плъгини и не позволявайте на другите сайтове да вграждат моя в рамка.

Как изглежда „добро”. Нашата проверка не просто търси присъствието на заглавката — тя чете политиката директива по директива и оценява колко е силна, по начина, по който би го направил проверяващ за сигурност. Силна политика:

Задава ограничителна база (default-src 'self') и само я разширява за конкретните доверени трети страни, реално използвани от вас.
Избягва вратичките. Не използва 'unsafe-inline' или 'unsafe-eval' за скриптове и не използва wildcard (*) или източници с гол схем (като https:) за скриптове — те ефективно отварят отново вратата, предназначена да затвори политиката. Където са наистина нужни вградени скриптове, използва nonce или hash, за да се изпълнява само вашият конкретен одобрен код.
Ограничава вграждането в рамка с frame-ancestors 'self' (това блокира и „вграждането на вашия сайт, за да заблудите клиентите ви”) и деактивира наследствените плъгини с object-src 'none'.
Е приложена, не само за докладване. Заглавката Content-Security-Policy-Report-Only само наблюдава; не осигурява никаква защита при изпълнение. Нашата проверка й дава малка fraction от кредита и никога не я записва като преминаване. Защитени сте само след като политиката е приложена.

Политика, съществуваща, но разчитаща на 'unsafe-inline', 'unsafe-eval' или wildcards, все пак ще получи ниска оценка — защото на практика осигурява малка реална защита. Целта е стегната политика, не просто каквато и да е политика.

Как да го поправите (безплатно, ~1–2 часа)

Предайте това на вашия IT специалист или когото управлява вашия уебсайт — самата поправка е напълно безплатна. Ние таксуваме само за мониторинг, че остава на място и правилна с течение на времето; включването й не струва нищо. Причината, поради която това отнема час или два вместо минути, е внимателната пробна стъпка, предотвратяваща случайното блокиране на части от вашия собствен сайт.

Стартирайте в режим само за докладване — не прилагайте засега. Добавете заглавка на отговора Content-Security-Policy-Report-Only. Тя наблюдава и регистрира какво би се блокирало без реално блокиране, така че живият сайт продължава да работи, докато научавате от какво реално зависи всяка страница. (Важно: само-за-докладване само по себе си не дава защита на посетителите — тя е само безопасната първа стъпка.)
Изградете политиката от реално използваното от сайта ви. Прегледайте докладите, за да намерите всеки легитимен източник на скриптове, стилове, шрифтове и изображения — вашия собствен домейн, анализите ви, доставчика ви на плащания, хоста на шрифтове, чат джаджата — и ги изброи като разрешени източници. Добра отправна точка е default-src 'self' плюс изрични записи за реално използваните от вас доверени трети страни.
Избягвайте вратичките, разрушаващи целия смисъл. Избягвайте 'unsafe-inline' и 'unsafe-eval' за скриптове и избягвайте wildcard източници като * и голи схеми като https: за скриптове — те отварят отново точно пропастта, предназначена да затвори политиката. Където вградените скриптове са неизбежни, използвайте nonce или hash, за да се изпълнява само вашият конкретен одобрен код.
Ограничете вграждането в рамка и плъгините. Добавете frame-ancestors 'self' (това спира и другите сайтове да вграждат вашия, за да заблудят клиентите ви, и удовлетворява свързаната проверка за защита срещу clickjacking) и object-src 'none', за да блокирате атаките, базирани на наследствени плъгини.
Превключете от само-за-докладване към приложена. След като докладите са чисти и сайтът работи, сменете нимето на заглавката от Content-Security-Policy-Report-Only на Content-Security-Policy. Тази стъпка е тази, която реално осигурява защита — политика само за докладване не го прави и няма да премине проверката.

Където задавате заглавката зависи от вашата платформа:
- Cloudflare: Rules → Transform Rules → Modify Response Header → задайте Content-Security-Policy. (Можете да използвате Cloudflare и за пробата само за докладване.)
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config): добавете персонализирана HTTP заглавка на отговора с ниме Content-Security-Policy и политиката като нейна стойност.
- Google Workspace / Microsoft 365: те управляват вашия имейл, а не вашия публичен уебсайт, така че политиката се задава там, където действително е хостван вашият уебсайт (Cloudflare или вашият уеб хост по-горе), а не в административната конзола на имейл.
Проверете отново вашия домейн, за да потвърдите, че политиката вече показва като включена и приложена, без отслабващи вратички.

Чести грешки

Спиране при само-за-докладване. Единствената най-честа грешка: политика се добавя в режим само за докладване, всички се разместват и сайтът никога не е реално защитен. Само-за-докладване не блокира нищо. Трябва да превключите към приложена.
Прибягване до 'unsafe-inline', за да „просто работи”. Когато политиката блокира легитимен вграден скрипт, бързата поправка е да се разрешат всички вградени скриптове — но това отваря отново точно дупката, предназначена да затвори политиката. Вместо това използвайте nonce или hash.
Използване на wildcard. Гол * (или https:) в script-src позволява скриптове отвсякъде, което означава, че политиката дава почти никаква реална защита и все пак ще получи ниска оценка.
Забравяне на източници от трети страни. Прилагането на строга политика без предварително изброяване на легитимните външни услуги, използвани от вас (анализи, шрифтове, джаджи за плащане), може да счупи части от вашия собствен сайт — именно поради това съществува пробната стъпка само за докладване.
Задаване й само на началната страница. Политиката трябва да обхваща всяка страница, особено тези за плащане, влизане и акаунт — именно те си заслужава да се атакуват.
Третиране й като заместител на катинара. CSP и HTTPS/HSTS защитават различни неща. Искате всичко; едното не покрива за другото.

ЧЗВ

Не съм технически — мога ли да се справя с това сам?

Нямате нужда да разбирате детайлите. Това е настройка, добавена от когото управлява вашия уебсайт или хостинг, а на услуги като Cloudflare е до голяма степен насочено. Предайте им раздела 'Как да го поправите' по-долу. Безплатно е; единственото предупреждение е, че трябва да бъде въведено внимателно в режим само за наблюдение първо, за да не блокира случайно части от вашия собствен сайт — именно това обхващат стъпките.

Вече имам катинар и SSL сертификат — сайтът ми сигурен ли е?

Катинарът осигурява доставката на вашата страница; не следи какво се изпълнява вътре в нея. Ако злонамерен код попадне на страница — чрез хакнат плъгин, компрометирана реклама или инжектирано поле — катинарът няма да го спре да краде данни. Политиката за сигурност на съдържанието е слоят, ограничаващ какво е разрешено да се изпълнява на първо място. Те защитават различни неща и искате и двете.

Може ли включването на това да счупи сайта ми?

Може, ако се включи агресивно наведнъж, защото може да блокира легитимни скриптове, реално използвани от вас. Затова стандартният подход е да се стартира в режим 'само за докладване', наблюдаващ без блокиране, да се поправи всичко, маркирано от него, и едва тогава да се приложи. Направено по този начин е безопасно — и пробният режим е вграден в поправката по-долу.

Вече го поставихме в 'само за докладване' режим — защитени ли сме?

Не, и това е най-честото фалшиво усещане за сигурност. Режимът само за докладване наблюдава и регистрира какво би било блокирано, но не блокира нищо — посетителите нямат реална защита. Той е само безопасната първа стъпка. Нашата проверка дава на само-за-докладване малка fraction от кредита на реална политика и няма да го запише като преминаване. Защитени сте само след превключване на приложения режим.

Засяга ли това оценката ни или е само консултативно?

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

Нашият разработчик добави политика, но оценката е все още ниска — защо?

Политика може да съществува и все пак да е слаба. Най-честите виновници са вратички като 'unsafe-inline' и 'unsafe-eval' за скриптове или wildcard източници (гол *), повторно отварящи точно пропастта, предназначена да затвори политиката. Нашата проверка чете политиката директива по директива и оценява надолу тези слабости — политика, позволяваща всичко, дава малко по-добра оценка от никаква. Поправката е да се стегнат правилата за скриптове с nonce или hash вместо тези вратички.