CSP (Content-Security-Policy)

A CSP nélkül egyetlen beszúrt szkript is elég ahhoz, hogy adatot lopjon vagy átirányítson. A bankkártyaadatokat kezelő oldalakon ez közvetlen pénzügyi és jogi kockázat.

A gyakorlati következmények:

• Egy feltört plugin által beszúrt külső szkript nem fut le, ha a script-src nem engedi.
• A frame-ancestors megakadályozza a clickjackinget, és kiváltja a régi X-Frame-Options fejlécet.
• Az upgrade-insecure-requests irányelvvel a mixed content (kevert tartalom) hibák nagy része eltűnik.

Az üzleti oldala egyszerű. Egy kompromittált webshop napokra kiesik, és a helyreállítás sokszorosába kerül, mint a fejléc beállítása. A CSP hatása egy auditban alacsony, mert a látogatók és a keresők nem érzékelik. A kockázatcsökkentése viszont valódi.

Mit néz ebből a riport

Az audit egyetlen dolgot ellenőriz: küld-e az oldal Content-Security-Policy fejlécet. Ha nincs, alacsony hatású hiányként jelenik meg, a hatókör pedig környezet vagy hoszting. A riport ajánlása ugyanaz, mint fent: állíts be CSP fejlécet az XSS elleni védelemhez.

Minden nyilvános weboldalra vonatkozik, de nem mindenhol egyforma a tét.

• Webshopok és bejelentkezést kérő oldalak: itt a legfontosabb, mert van mit ellopni.
• Céges bemutatkozó oldalak: itt is ajánlott, mert a feltört oldal a márkát viszi el.
• Landing oldalak sok külső szkripttel: nehezebb dolgod van, de megoldható nonce-szal.

Ahol nem éri meg erőltetni: staging és belső, jelszóval védett környezetek. Ott a hozzáférés-korlátozás a hatékonyabb eszköz. Bérelt SaaS-platformon (webshop-motorok) gyakran nincs jogod válaszfejlécet állítani. Ilyenkor a platform alapbeállítása marad, és ez nem a te hibád.

1. Nyisd meg az oldalt, indítsd el a böngésző devtools Network fülét, és töltsd újra az oldalt.
2. Kattints a fő HTML-dokumentumra, majd nézd meg a Response Headers blokkot.
3. Keresd a content-security-policy sort. Parancssorból ugyanez: curl -sI https://pelda.hu.
4. Váltsd át a Console fülre, és keress Refused to load vagy Refused to execute üzeneteket.
5. Másold be a szabályt a Google CSP Evaluator eszközébe, és nézd meg, mit talál gyengének.
6. Egyben az összes fejlécet a securityheaders.com is megmutatja.

Jó jel:

• Van Content-Security-Policy fejléc, és tartalmaz default-src irányelvet.
• A script-src nonce-t vagy hasht használ, nem csillagot.
• Szerepel benne object-src 'none' és base-uri 'self'.
• A konzol tiszta, nincs blokkolási hiba.

Rossz jel:

• Nincs fejléc, vagy csak <meta> tagben van (ott a frame-ancestors nem működik).
• A script-src értéke 'unsafe-inline' 'unsafe-eval' vagy *.
• A konzol tele van blokkolt szkriptekkel, és emiatt funkciók dőlnek el.
• Csak a kezdőlapon van fejléc, az aloldalakon nincs. Ezt a HTTPS és TLS beállításokkal együtt érdemes végigellenőrizni.

Az alapelv mindenhol azonos. Először Content-Security-Policy-Report-Only fejléccel indulj, gyűjtsd a hibákat 1-2 hétig, és csak utána élesítsd.

WordPress

1. Ha van hozzáférésed a szerverhez, a fejlécet az nginx vagy Apache konfigban add hozzá. Ez a legstabilabb.
2. Ha nincs, használj biztonsági bővítményt, amelyben egyedi HTTP-fejléceket állíthatsz.
3. Kódból a send_headers hookban is beállíthatod a gyerektémában.
4. Futtasd végig a kritikus oldalakat: kosár, pénztár, űrlapok, admin.

Shopify

1. A storefront válaszfejléceit a platform adja, saját CSP-t nem tudsz beállítani.
2. A pénztár-oldalak CSP-jét a Shopify kezeli, ehhez nem kell hozzányúlnod.
3. Amit tehetsz: csökkentsd a felesleges appokat és külső szkripteket a témában.

Unas

1. Egyedi válaszfejlécek beállítására nincs felhasználói felület.
2. Ha szükséged van rá, kérdezd meg az ügyfélszolgálatot a lehetőségekről.
3. A saját sablonkódban kerüld az inline szkripteket, hogy később könnyebb legyen.

Shoprenter

1. A fejlécek a platform oldalán dőlnek el, a sablonszerkesztő nem ad rá lehetőséget.
2. Az egyedi kódbeillesztéseket tartsd külön fájlban, ne inline-ban.

Egyedi fejlesztés

1. nginx alatt add_header Content-Security-Policy "..." always; formában add ki.
2. Apache alatt Header always set Content-Security-Policy "..." a megfelelő sor.
3. Generálj kérésenként véletlen nonce-t, és tedd rá minden saját <script> tagre.
4. A Google Tag Manager (GTM) és más címkekezelők miatt gyakran kell 'strict-dynamic', mert futásidőben töltenek be szkripteket.
5. Állíts be report-uri vagy report-to végpontot, hogy lásd a valódi sérüléseket.

• Nincs fejléc egyáltalán: a legelterjedtebb eset, a védelem nulla.
• script-src 'unsafe-inline': pont azt engedi meg, ami ellen a CSP véd, így a szabály dísz lesz.
• Csillag a forrásoknál: a default-src * bármilyen domainről enged betöltést, vagyis nem korlátoz.
• Éles bevezetés tesztelés nélkül: a kosár vagy az űrlap elhal, és napokig senki nem veszi észre.
• Csak meta tagben beállítva: a frame-ancestors és a riportálás így nem működik.
• Egymásnak mondó fejlécek: ha kettő is kimegy, a böngésző mindkettőt betartatja, és a szigorúbb nyer.
• A riportálás kikapcsolva marad: nem látod, mit blokkol a szabály a valódi látogatóknál.

Egy használható kiindulási szabály, nonce-alapú szkript-engedéllyel:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{RANDOM}' 'strict-dynamic' https:; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' https:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests

A {RANDOM} helyére kérésenként új, véletlen érték kerül. Ugyanez az érték megy a HTML-be: <script nonce="{RANDOM}">.

Ellenőrzés parancssorból, csak a lényeges sorokra szűrve:

curl -sI https://pelda.hu | grep -i "content-security-policy"

Ha üres a válasz, nincs beállítva a fejléc. Bevezetés előtt cseréld a fejléc nevét Content-Security-Policy-Report-Only értékre. Így semmit nem blokkol, csak jelent.