Defaults.Exposed › Ispravci › Content-Security-Policy (CSP)

Kako popraviti Content-Security-Policy (CSP)

Content Security Policy je sigurnosno pravilo koje vaša web stranica predaje pregleniku svakog posjetitelja, govoreći mu točno koji je kod dopušteno pokretati. Bez njega, ako ikad nešto zlonamjerno dospije na stranicu — putem polja za komentare, hakiranog dodatka ili skripte treće strane — preglednik će ga slobodno pokrenuti, uključujući kod koji tiho presreće brojeve kartica i lozinke vaših klijenata dok upisuju, a lokot ostaje prikazan.

Zaključak za vaše poslovanje: Ako se vaša stranica ikad izmijeni, zlonamjerni kod može izravno s vaše naplatne stranice čitati podatke kartice i prijave vaših klijenata dok sve izgleda potpuno normalno — ostavljajući vas s povratnim naplatama, pritužbama o prijevari, prijavljivim kršenjem podataka i propastom provjere koji veći klijenti koriste za blokiranje ili ubijanje posla.

Što vas ovo može koštati

Skriven kod provuče se na jednu od vaših stranica i tiho kopira svaki broj kartice i lozinku koje vaši klijenti unesu pri naplati, šaljući to napadaču u stvarnom vremenu dok vaša stranica izgleda i funkcionira savršeno — saznate tek kad stignu pritužbe o prijevari.
Prevarant postavi lažni 'plati ovdje' obrazac na vašu pravu web stranicu koji presreće plaćanja na vlastiti račun; klijenti misle da su platili vama, okrive vas kad roba ne stigne i traže povrat.
Sigurnosni tim većeg klijenta skenira vašu stranicu, vidi da je ova osnovna zaštita isključena i to označi — blokirajući ili gubite ugovor dok ne dokažete da je ispravljeno.
Kršenje koje se prati na nedostajuću standardnu zaštitu postaje prijavljivi incident: pitanja regulatora, obavijesti klijentima i reputacijski udarac koji košta daleko više od besplatnog popravka.

Zašto je to važno. Lokot dokazuje da je veza s vašom stranicom privatna, ali ništa ne kontrolira koji kod se pokreće kad je posjetitelja na stranici. Content Security Policy je zaštita koja to radi — govori preglednicima da ignoriraju sve skripte koje nisu došle iz izvora koji ste vi povjerili, pa jedno izmijenjeno polje, oglas ili dodatak ne može postati alat za krađu novca i podataka vaših klijenata. To je bodovana provjera na vašoj ljestvici, vrijedi prave bodove i jedno od prvih stvari koje profesionalni sigurnosni pregled traži.

Što je ovo, jednostavnim riječima

Kad netko posjeti vašu web stranicu, njihov preglednik preuzme vašu stranicu i pokrene sav kod na njoj — skripte koje čine menije padajućima, gumbe funkcionalnima, platne obrasce šaljivima i tako dalje. Po zadanom, preglednik mu svemu vjeruje. Nema načina da zna koji kod je genuinno vaš, a koji je ubacio netko drugi.

Content Security Policy (često skraćeno na CSP) je kratki popis pravila koji vaša web stranica prilaže svakoj stranici, govoreći pregjedniku: “pokreni samo kod iz ovih izvora koje sam odobrio, i odbij sve ostalo.” To je razlika između noćnog kluba koji pušta svakoga i onog s popisom gostiju na ulazu.

Razlog zašto je ovo toliko važno je taj što se web stranice stalno mijenjaju — ne uvijek hakiranjem vašeg servera, već kroz zadnja vrata koja većina stranica ostavi otvorena: polje za komentare, okvir za pretraživanje, zastarjeli dodatak, skripta treće strane za oglase ili analitiku, ili chat widget. Ako napadač ubaci i jedan redak svog koda na jednu vašu stranicu, preglednik ga pokrenuti kao da je vaš. Odatle može čitati sve što vaši klijenti tipkaju — brojeve kartica, lozinke, adrese — i tiho to poslati drugdje. Content Security Policy zatvara ta vrata odbijajući pokretanje bilo čega iz izvora koji niste odobrili.

Što vas ovo može koštati

Ovo nije apstraktno. Napad koji Content Security Policy sprječava — kod ubačen u stranicu koji krade podatke od vaših vlastitih klijenata — iza je nekih od najvećih kršenja presretanja kartica na rekord. Evo kako to obično ispadne za normalno poduzeće:

Nevidljivi presretač pri naplati. Napadač provuče nekoliko redaka koda na vašu stranicu naplate kroz ranjivi dodatak ili kompromitirani script treće strane. Svaki broj kartice, ime i CVV koje vaši klijenti upisuju kopira se i šalje napadaču u stvarnom vremenu. Vaša stranica izgleda i funkcionira savršeno; lokot je tu. Otkrijete to tjednima kasnije kad vas vaš pružatelj plaćanja nazove zbog grozda pritužbi o prijevari koje se prate natrag na vašu trgovinu. Sada se suočavate s povratnim naplatama, prisiljenom sigurnosnom revizijom, mogućim gubitkom prava na kartično procesiranje i kršenjem koje ste možda zakonski dužni prijaviti.
Lažni platni obrazac. Prevarant ubaci uvjerljivi “plati ovdje” okvir na vašu pravu web stranicu. Klijenti unose svoje podatke vjerujući vašem brendu; novac i podaci idu napadaču. Klijenti vas okrive — i nisu pogrešni, jer se to dogodilo na vašoj stranici.
Izgubljeni ugovor. Sigurnosni tim većeg potencijalnog partnera pokrene automatizirano skeniranje vaše stranice kao dio due diligence dobavljača. Nedostajuća Content Security Policy odmah se pojavi kao visoko-ozbiljan propust. Pregledatelju nabave ili sigurnosti, taj jedan nedostajući zaštitnik čita se kao “ovaj dobavljač ne radi osnove” — i posao stoji dok ne traže sanaciju, ili tiho ide konkurentu koji je prošao provjeru.
Prijavljivo kršenje. Kad se kršenje podataka prati natrag na nedostajući, standardni, besplatni zaštitnik, prestaje biti loša sreća i počinje izgledati kao nemar. To mijenja pitanja regulatora, obvezu obavještavanja klijenta i trošak — i novčanu kaznu i reputacijsku štetu, koja traje mnogo dulje nakon što je incident zatvoren.
Kompromitirani oglas ili widget. Mnoge stranice učitavaju kod od vanjskih strana — reklamne mreže, fontove, podršku za chat, analitiku. Ako se bilo koje od njih kompromitira, zlonamjerni kod ulazi izravno na vaše stranice. Content Security Policy ograničava štetu dopuštajući samo specifične vanjske izvore kojima vjerujete, pa kršenje jednog dobavljača ne postane automatski i vaše.

Što je to zapravo (detalji)

Content Security Policy se isporučuje kao jedno HTTP zaglavlje odgovora — redak koji vaš web server šalje sa svakom stranicom. Njegova vrijednost je skup direktiva, svaka koja imenuje vrstu sadržaja i dopuštene izvore za njega. Na primjer:

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

Slobodnim prijevodom, to kaže: po zadanom učitavaj samo stvari s moje vlastite stranice; pokreći samo skripte s moje vlastite stranice; ne dopusti stare dodatke; i ne dopusti drugim stranicama da ugnjezde mene u okvir.

Kako izgleda ‘dobro’. Naša provjera ne gleda samo jesu li zaglavlje prisutno — čita politiku direktivu po direktivu i boduje koliko je zapravo jaka, onako kao što bi to učinio sigurnosni recenzent. Jaka politika:

Postavlja restriktivnu osnovu (default-src 'self') i širi je samo za specifične pouzdane treće strane koje genuinno koristite.
Izbjegava rupe. Ne koristi 'unsafe-inline' ili 'unsafe-eval' za skripte, i ne koristi zamjenski (*) ili gole sheme izvora (poput https:) za skripte — ovo zapravo ponovo otvara vrata koja politika treba zatvoriti. Tamo gdje su inline skripte zaista potrebne, koristi nonce ili hash pa se pokreće samo vaš specifični odobren kod.
Zaključava uokvirivanje s frame-ancestors 'self' (ovo blokira i “ugnijezdite vašu stranicu da prevarite vaše klijente” napad) i onemogućuje naslijeđene dodatke s object-src 'none'.
Provodi, ne samo za izvještavanje. Content-Security-Policy-Report-Only zaglavlje samo promatra; ne pruža nikakvu zaštitu u stvarnom vremenu. Naša provjera daje mu mali dio kredita i nikad ga ne bilježi kao prolaz. Zaštićeni ste tek kad je politika provedbe.

Politika koja postoji, ali se oslanja na 'unsafe-inline', 'unsafe-eval' ili zamjenske znakove, još uvijek će se loše bodovati — jer u praksi pruža malo stvarne zaštite. Cilj je tijesna politika, ne samo neka politika.

Kako to popraviti (besplatno, ~1–2 sata)

Proslijedite ovo vašoj IT osobi ili onome tko vodi vašu web stranicu — sam popravak je potpuno besplatan. Mi naplaćujemo samo praćenje da ostane na mjestu i ostane ispravno; uključivanje ne košta ništa. Razlog zašto ovo traje sat ili dva umjesto minutama je pažljivi probni korak koji sprječava slučajno blokiranje dijelova vaše vlastite stranice.

Krenite u modu samo za izvještavanje — još ne provodite. Dodajte Content-Security-Policy-Report-Only zaglavlje odgovora. Ovo promatra i bilježi što bi bilo blokirano bez da zapravo blokira bilo što, pa živa stranica nastavlja raditi dok učite na čemu svaka stranica zaista ovisi. (Važno: samo za izvještavanje samo po sebi ne daje posjetiteljima nikakvu zaštitu — to je samo siguran prvi korak.)
Izgradite politiku od onoga što vaša stranica zapravo koristi. Pregledajte izvješća da pronađete svaki legitimni izvor skripti, stilova, fontova i slika — vašu vlastitu domenu, analitiku, pružatelja plaćanja, hosta fontova, chat widget — i navedite ih kao dopuštene izvore. Čvrsta polazna točka je default-src 'self' plus eksplicitni unosi za pouzdane treće strane koje zaista koristite.
Izbjegajte rupe koje poništavaju cijelu svrhu. Klonite se 'unsafe-inline' i 'unsafe-eval' za skripte i izbjegajte zamjenske izvore poput * i gole sheme poput https: za skripte — ove ponovo otvaraju točno onu prazninu koju politika treba zatvoriti. Tamo gdje su inline skripte neizbježne, koristite nonce ili hash da samo vaš specifični odobreni kod se pokreće.
Zaključajte uokvirivanje i dodatke. Dodajte frame-ancestors 'self' (ovo i sprečava druge stranice da ugniježduju vaše za varanje vaših klijenata, i zadovoljava povezanu clickjacking provjeru) i object-src 'none' za blokiranje naslijeđenih napada zasnovanih na dodacima.
Prijeđite s samo za izvještavanje na provedbu. Jednom kad su izvješća čista i stranica radi, promijenite naziv zaglavlja iz Content-Security-Policy-Report-Only na Content-Security-Policy. Ovo je korak koji zapravo pruža zaštitu — politika samo za izvještavanje sama to ne radi, i neće proći provjeru.

Gdje postavljate zaglavlje ovisi o vašoj platformi:
- Cloudflare: Rules → Transform Rules → Modify Response Header → postavi Content-Security-Policy. (Možete koristiti Cloudflare i za probni samo-za-izvještavanje trial.)
- 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): dodajte prilagođeno HTTP zaglavlje odgovora nazvano Content-Security-Policy s politikom kao vrijednošću.
- Google Workspace / Microsoft 365: ovi pokreću vašu e-poštu, ne vašu javnu web stranicu, pa je politika postavljena gdje god je vaša web stranica zapravo hostana (Cloudflare ili vaš web host gore), ne u vašoj e-poštanskoj admin konzoli.
Ponovo provjerite svoju domenu da potvrdite da politika sada prikazuje kao uključena i provodi, bez slabljujućih rupa.

Česte greške

Zaustavljanje na samo za izvještavanje. Najčešća greška: politika se dodaje u modu samo za izvještavanje, svi se prebace na nešto drugo, i stranica nikad zapravo nije zaštićena. Samo za izvještavanje ništa ne blokira. Morate prijeći na provedbu.
Posizanje za 'unsafe-inline' da “samo radi”. Kad politika blokira legitimnu inline skriptu, brzi popravak je dopustiti sve inline skripte — ali to ponovo otvara točno onu rupu politika je trebala zatvoriti. Umjesto toga koristite nonce ili hash.
Korištenje zamjenskog znaka. Goli * (ili https:) u script-src dopušta skripte odakle god, što znači da politika pruža gotovo nikakvu pravu zaštitu i svejedno se loše boduje.
Zaboravljanje izvora treće strane. Provedba stroge politike bez prvog navođenja legitimnih vanjskih usluga koje koristite (analitika, fontovi, platni widgeti) može pokvariti dijelove vaše vlastite stranice — to je točno zašto postoji korak probnog samo-za-izvještavanje triala.
Postavljanje samo na početnoj stranici. Politika treba pokrivati svaku stranicu, posebno naplatu, prijavu i stranice računa — to su one koje vrijedi napadati.
Tretiranje kao zamjenu za lokot. Content Security Policy i HTTPS/HSTS štite različite stvari. Trebate sve; jedno ne pokriva za drugo.

Česta pitanja

Nisam tehničar — mogu li ovo sam riješiti?

Ne trebate razumjeti detalje. Ovu postavku dodaje onaj tko vodi vašu web stranicu ili hosting, a na uslugama poput Cloudflarea uglavnom je vođeno. Proslijedite im odjeljak 'Kako to popraviti' u nastavku. Besplatno je; jedina opreznost je da ga treba uvesti pažljivo u probnom načinu samo za praćenje prvom da ne blokira slučajno dijelove vaše vlastite stranice — što je točno ono što koraci pokrivaju.

Već imam lokot i SSL certifikat — nije li moja stranica sigurna?

Lokot osigurava dostavu vaše stranice; ne nadzire što se pokreće unutar nje. Ako zlonamjerni kod ikad dospije na stranicu — putem hakiranog dodatka, kompromitiranog oglasa ili ubačenog polja — lokot ga neće spriječiti da krade podatke. Content Security Policy je sloj koji ograničava što je dopušteno pokretati od početka. Štite različite stvari, i oboje trebate.

Može li uključivanje ovoga pokvariti moju stranicu?

Može ako se uključi agresivno odjednom, jer može blokirati legitimne skripte koje zaista koristite. Upravo zato standardni pristup je krenuti u 'samo za izvještavanje' probnom modu koji promatra bez blokiranja, ispraviti sve što označi i tek tada provoditi. Na ovaj način je sigurno — a probni korak ugrađen je u popravak u nastavku.

Već smo ga stavili u 'samo za izvještavanje' — jesmo li pokriveni?

Ne, i ovo je najčešći lažni osjećaj sigurnosti. Mod samo za izvještavanje promatra i bilježi što bi bilo blokirano, ali ništa ne blokira — posjetitelji ne dobivaju nikakvu pravu zaštitu. To je samo siguran prvi korak. Naša provjera daje samo za izvještavanje mali dio kredita prave politike i to ne bilježi kao prolaz. Zaštićeni ste tek kad prijeđete na mod provedbe.

Utječe li ovo na naš rezultat, ili je samo savjetodavno?

Utječe na vaš rezultat. Provjera Content Security Policy je bodovana i vrijedi do 25 bodova u kategoriji Web Security. Nedostajuća ili slaba politika je označena visoke ozbiljnosti i vleče vašu ocjenu dolje — i to je točno vrsta propusta o kojoj sigurnosni upitnik klijenta pita.

Naš programer je dodao politiku, ali rezultat je još uvijek nizak — zašto?

Politika može postojati i još uvijek biti slaba. Najčešnji krivci su rupe poput 'unsafe-inline' i 'unsafe-eval' za skripte, ili zamjenski izvori (goli *), koji ponovo otvaraju točno onu prazninu koju politika treba zatvoriti. Naša provjera čita politiku direktiva po direktiva i boduje niže te slabosti — politika koja bilo što dopušta malo bolje se boduje od nepostojanja nijedne. Popravak je postrožiti pravila skripti korištenjem nonces ili hashes umjesto tih rupa.