Defaults.Exposed › Javítások › Content-Security-Policy (CSP)

Hogyan javítsd ki: Content-Security-Policy (CSP)

A Content Security Policy egy biztonsági szabály, amelyet a webhelyed minden látogató böngészőjének átad, megmondva pontosan, milyen kódok futhatnak. Nélküle, ha bármi rosszindulatú kerül egy oldalra – egy megjegyzőmező, egy feltört bővítmény vagy egy harmadik feles szkript révén –, a böngésző szabadon futtatja, beleértve a kódot, amely csendesen leolvasja az ügyfelek kártyaszámait és jelszavait, ahogy beírják azokat, miközben a lakat még mindig mutat.

Az üzleted szempontjából lényeg: Ha az oldalt valaha illetéktelenül módosítják, a rosszindulatú kód közvetlenül a saját pénztáradból olvashatja le az ügyfelek fizetési kártyaadatait és bejelentkezési adatait, miközben minden teljesen normálisnak tűnik – visszaterheléseket, csalási igényeket, bejelentendő adatvédelmi incidenseket és biztonsági ellenőrzési eredményt hagyva, amelyet a nagyobb ügyfelek biztonsági csapatai az üzlet megállítására vagy megsemmisítésére használnak.

Mibe kerülhet ez neked

• Rejtett kód bekerül az egyik oldaladra, és csendesen másolja az összes kártyaszámot és jelszót, amelyet az ügyfeleid a pénztárnál beírnak, elküldi egy támadónak, miközben az oldalad teljesen normálisnak tűnik – csak akkor tudod meg, amikor megérkeznek a csalási panaszok.
• Egy csaló hamis 'fizessen itt' űrlapot ültet el a valódi webhelyeden, amely a saját számlájára fogja a kifizetéseket; az ügyfelek azt hiszik, neked fizettek, amikor az áruk nem jönnek meg, visszakövetelnek, és vissza akarják a pénzüket.
• Egy nagyobb ügyfél biztonsági csapata megvizsgálja az oldalt, látja, hogy ez az alap védelem ki van kapcsolva, és megjelöli – megállítva vagy elveszítve a szerződést, amíg nem bizonyítod, hogy javítottál.
• Egy hiányzó szabványos védőeszközre visszavezethető feltörés bejelentendő incidensé válik: szabályozói kérdések, ügyfél-értesítések és hírnévkárosodás, amely sokkal többe kerül, mint az ingyenes javítás.

Miért fontos. A lakat bizonyítja, hogy a kapcsolat az oldaladon privát, de semmit sem tesz annak ellenőrzéséért, milyen kódok futnak, amint a látogató az oldalon van. A Content Security Policy az a védőeszköz, amely ezt csinálja – megmondja a böngészőknek, hogy hagyják figyelmen kívül a olyan szkripteket, amelyek nem az általad megbízott forrásokból érkeznek, tehát egyetlen manipulált mező, hirdetés vagy bővítmény sem válhat az ügyfelek pénzét és adatait ellopó eszközzé. Ez egy pontozásos ellenőrzés az eredménylapodon, valódi pontokat ér, és az egyike az első dolgoknak, amelyet egy szakmai biztonsági felülvizsgálat keres.

Mi ez egyszerű szavakkal

Amikor valaki meglátogatja a weboldaladat, a böngészőjük letölti az oldaladat és futtatja a rajta lévő kódot – a szkripteket, amelyek legördülő menüket, gombokat, fizetési űrlapokat, stb. működtetnek. Alapból a böngésző megbízik mindenben. Nincs módja tudni, melyik kód valóban a tiéd, és melyiket csempészte be valaki más.

A Content Security Policy (gyakran CSP-nek rövidítve) egy rövid szabálylista, amelyet a webhelyed minden oldalhoz mellékel, megmondva a böngészőnek: „csak az általam jóváhagyott forrásokból futtass kódot, és utasíts vissza mindent mást.” Ez a különbség egy olyan éjszakai klub között, amely mindenkit beenged, és egy vendéglistával rendelkező között.

Ennek azért van akkora jelentősége, mert a webhelyeket folyamatosan manipulálják – nem mindig a szervered feltörésével, hanem a legtöbb oldal által nyitva hagyott hátsó ajtókon keresztül: egy megjegyzőmező, egy keresőmező, egy elavult bővítmény, egy harmadik feles hirdetési vagy analitikai szkript, vagy egy chat widget. Ha egy támadó egyetlen sort is el tud juttatni a saját kódjából az egyik oldaladra, a böngésző úgy futtatja, mintha a tiéd lenne. Onnantól mindent olvashatja, amit az ügyfeleid begépelnek – kártyaszámokat, jelszavakat, adatokat –, és csendesen elküldheti máshova. A Content Security Policy bezárja ezt az ajtót azáltal, hogy megtagadja az olyan forrásokból érkező futtatást, amelyeket nem hagytál jóvá.

Mibe kerülhet ez neked

Ez nem elvont. A Content Security Policy által megelőzött támadás – egy oldalba befecskendezett kód, amely adatokat lop az ügyfeleidtől –, a legnagyobb kártya-leolvasó feltörések mögött áll. Így szokott kinézni egy normál vállalkozásnál:

• A láthatatlan pénztár-leolvasó. Egy támadó néhány kódsort csillagol el a pénztár oldaladba egy sebezhető bővítményen vagy egy kompromittált harmadik feles szkripten keresztül. Minden kártyaszámot, nevet és CVV-t, amelyet az ügyfeleid beírnak, valós időben lemásolja és elküldi a támadónak. Az oldal tökéletesen néz ki és működik; a lakat ott van. Hetekkel később deríted ki, amikor a fizetési szolgáltatód hív a csalási bejelentések egy csoportjáról, amelyek mindegyike a boltodig vezet vissza. Most visszaterhelésekkel, kényszerített biztonsági audittal, esetleges kártyafeldolgozási jogvesztéssel és egy bejelentendő feltöréssel szembesülsz.

• A hamis fizetési űrlap. Egy csaló egy meggyőző ‘fizessen itt’ dobozt fecskendez el a valódi webhelyedre. Az ügyfelek a márkádat megbízva beírják az adataikat; a pénz és az adatok a támadóhoz mennek. Az ügyfelek téged hibáztatnak – és nem tévesen, mert ez a te oldaladon történt.

• Az elveszett szerződés. Egy nagyobb lehetséges ügyfél biztonsági csapata automatizált vizsgálatot futtat az oldalon a szállítói kellő gondosság részeként. Egy hiányzó Content Security Policy azonnal magas súlyosságú résként jelenik meg. Egy beszerzési vagy biztonsági felülvizsgáló számára ez az az egyetlen hiányzó védőeszköz azt olvassa: ‘ez a szállító nem csinálja az alapokat’ – és az üzlet megáll, amíg javítást kérnek, vagy csendesen egy olyan versenytárshoz megy, aki megfelelt.

• A bejelentendő feltörés. Amikor egy adatvédelmi feltörés visszavezethető egy hiányzó, szabványos, ingyenes védőeszközre, megszűnik balszerencsének lenni, és gondatlanságnak kezd tűnni. Ez megváltoztatja a szabályozói kérdéseket, az ügyfél-értesítési kötelezettséget és a költséget – mind a bírságot, mind a hírnévkárosodást, amely az incidens lezárása után sokáig tart.

• A kompromittált hirdetés vagy widget. Sok oldal kívülről tölt kódot – hirdetőhálózatokból, betűtípusokból, ügyfélszolgálati chátből, analitikából. Ha ezek bármelyike feltört, a rosszindulatú kód egyenesen bekerül az oldalaidba. Egy Content Security Policy korlátozza a robbanás sugarát azáltal, hogy csak azokat a speciális külső forrásokat engedi meg, amelyekben megbízol, tehát egy szállítói feltörés nem válik automatikusan a tiedévé.

Mi is ez pontosan (a részletek)

A Content Security Policy egyetlen HTTP válasz fejlécként kerül kézbesítésre – egy sor, amelyet a webszervered minden oldalhoz küld. Az értéke direktívák készlete, mindegyik névvel lát egy tartalom-típust és az ahhoz engedélyezett forrásokat. Például:

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

Egyszerű szavakkal: alapból csak a saját oldalamról töltsd be a dolgokat; csak a saját oldalamból futtass szkripteket; ne engedélyezz régi stílusú bővítményeket; és ne engedd, hogy más oldalak keretbe záruljak.

Mit jelent a „jó” beállítás. Az ellenőrzésünk nem csak a fejléc meglétét nézi – direktívánként olvassa a politikát, és úgy pontozza, mennyire erős, ahogy egy biztonsági felülvizsgáló tenné. Egy erős politika:

• Korlátozó alapot állít be (default-src 'self'), és csak a ténylegesen használt megbízott harmadik felekre szélesíti.
• Elkerüli a kiskapukat. Nem használ 'unsafe-inline'-t vagy 'unsafe-eval'-t szkriptekre, és nem használ helyettesítő karaktert (*) vagy bare-scheme forrásokat (mint a https:) szkriptekre – ezek lényegében újra megnyitják azt a rést, amelyet a politika hivatott bezárni. Ahol az inline szkriptek valóban szükségesek, nonce-ot vagy hash-t használ, hogy csak az adott jóváhagyott kód futhasson.
• Bezárja a keretet a frame-ancestors 'self' segítségével (ez megállítja a ‘beágyazd az oldaladat, hogy megcsald az ügyfeleidet’ támadást), és letiltja a régi bővítményeket az object-src 'none' segítségével.
• Kényszerítés, nem report-only. Egy Content-Security-Policy-Report-Only fejléc csak figyel; nulla futási idejű védelmet nyújt. Az ellenőrzésünk a kredit töredékét adja, és soha nem rögzíti megfelelésként. Csak akkor vagy védve, amint a politika kényszerítve van.

Egy politika, amely létezik, de 'unsafe-inline'-ra, 'unsafe-eval'-ra vagy helyettesítő karakterekre támaszkodik, még mindig alacsonyra pontozódik – mert a gyakorlatban kevés valódi védelmet nyújt. A cél egy szoros politika, nem csupán bármilyen politika.

Hogyan javítsd ki (ingyenes, ~1–2 óra)

Add ezt az IT-személyednek vagy annak, aki a weboldaladat kezeli – maga a javítás teljesen ingyenes. Mi csak azért számítjuk fel a díjat, hogy figyeljük, hogy idővel érvényes marad és helyes marad; a bekapcsolás semmibe sem kerül. Az ok, amiért ez percek helyett egy-két órát vesz igénybe, az a gondos próba-lépés, amely megakadályozza, hogy az oldal részei véletlenül blokkolódjanak.

1. Kezdj report-only módban – még ne kényszerítsd. Adj hozzá egy Content-Security-Policy-Report-Only válasz fejlécet. Ez figyel és naplóz, mi lenne blokkolva anélkül, hogy ténylegesen blokkolna bármit, tehát az élő oldal tovább működik, amíg megtanulod, mitől függ valóban minden oldal. (Fontos: a report-only önmagában semmi védelmet nem ad a látogatóknak – ez csak a biztonságos első lépés.)

2. Építsd fel a politikát abból, amit az oldal ténylegesen használ. Nézd át a jelentéseket, hogy megtaláld a szkriptek, stílusok, betűtípusok és képek minden legitim forrását – a saját domained, az analitikád, a fizetési szolgáltatód, a betűtípus-hosztod, a chat widgeted –, és sorold fel őket engedélyezett forrásként.

3. Kerüld a kiskapukat, amelyek megsemmisítik az egész pontot. Kerüld el az 'unsafe-inline'-t és az 'unsafe-eval'-t a szkriptekhez, és kerüld a helyettesítő forrásokat, mint a * és bare sémák, mint a https: a szkriptekhez. Ahol az inline szkriptek elkerülhetetlenek, használj nonce-ot vagy hash-t, hogy csak az adott jóváhagyott kódod futhasson.

4. Zárd le a keretet és a bővítményeket. Add hozzá a frame-ancestors 'self'-et (ez is megállítja azt, hogy más oldalak beágyazzák a tiedet, hogy megtévesszék az ügyfeleidet), és az object-src 'none'-t a régi bővítmény-alapú támadások blokkolásához.

5. Váltás report-only-ről kényszerítésre. Amint a jelentések tiszták, és az oldal működik, változtasd meg a fejléc nevét Content-Security-Policy-Report-Only-ról Content-Security-Policy-ra. Ez a lépés nyújtja a valódi védelmet – önmagában egy report-only politika nem teszi ezt, és nem fogja átmenni az ellenőrzést.

   Ahol beállítod a fejlécet, a platformodtól függ:

   • Cloudflare: Rules → Transform Rules → Modify Response Header → állítsd be a Content-Security-Policy-t.
   • 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): adj hozzá egy egyéni HTTP válasz fejlécet Content-Security-Policy névvel, a politikával mint értékkel.

6. Ellenőrizd újra a domained, hogy erősítsd meg, a politika most bekapcsoltnak és kényszerítettnek mutat-e, gyengítő kiskapuk nélkül.

Általános hibák

• Report-only-nál megállni. A leggyakoribb hiba: egy politikát report-only módban adnak hozzá, mindenki továbblép, és az oldal soha valóban nem védett. A report-only semmit sem blokkol. Kényszerítésre kell váltani.
• 'unsafe-inline'-hoz nyúlni, hogy ‘csak működjön’. Amikor a politika blokkolja a legitim inline szkriptet, a gyors javítás az összes inline szkript engedélyezése – de ez újra megnyitja pontosan azt a lyukat, amelyet a politika hivatott bezárni. Használj nonce-ot vagy hash-t helyette.
• Helyettesítő karakter használata. Egy üres * (vagy https:) a script-src-ben mindenhonnan engedélyezi a szkripteket, ami azt jelenti, hogy a politika szinte semmilyen valódi védelmet nem nyújt.
• Harmadik feles forrásokról megfeledkezni. Egy szigorú politika kényszerítése anélkül, hogy először listáznád a ténylegesen használt legitim külső szolgáltatásokat (analitika, betűtípusok, fizetési widgetek) tönkreteheti az oldal egyes részeit – pontosan ezért létezik a report-only próba-lépés.
• Csak a kezdőoldalon beállítani. A politikának minden oldalt le kell fedni, különösen a pénztárat, a bejelentkezési és a fiókos oldalakat – ezek megéri megtámadni.
• Lakathelyettesítőként kezelni. A Content Security Policy és a HTTPS/HSTS különböző dolgokat védenek. Mindegyiket akarod; az egyik nem fedi a másikat.

GYIK