Frontend biztonsági fejlécek: A Content Security Policy (CSP) mesterfogásai

Napjaink digitális világában, ahol a webalkalmazások egyre összetettebbek és összekapcsoltabbak, a biztonsági fenyegetések elleni védekezés kiemelten fontos. Míg a backend biztonság gyakran jelentős figyelmet kap, a frontend biztonság éppolyan kulcsfontosságú. A frontend biztonsági fejlécek az első védelmi vonalként működnek, mechanizmust biztosítva a böngészőnek arra, hogy hogyan viselkedjen, és megvédje a felhasználókat a különböző támadásoktól. Ezen fejlécek közül a Content Security Policy (CSP) kiemelkedik mint hatékony eszköz a kockázatok széles körének csökkentésére.

Mik azok a frontend biztonsági fejlécek?

A frontend biztonsági fejlécek olyan HTTP válaszfejlécek, amelyeket a webszerver küld a böngészőnek. Ezek a fejlécek utasításokat tartalmaznak arra vonatkozóan, hogy a böngésző hogyan kezelje a kapott tartalmat. Segítenek megelőzni az olyan gyakori támadásokat, mint:

• Cross-Site Scripting (XSS): Kártékony szkriptek bejuttatása megbízható webhelyekre.
• Clickjacking: A felhasználók megtévesztése, hogy valami másra kattintsanak, mint amit látnak.
• Man-in-the-Middle (közbeékelődéses) támadások: A felhasználó és a szerver közötti kommunikáció elfogása.

Néhány a legfontosabb frontend biztonsági fejlécek közül:

• Content Security Policy (CSP): Meghatározza azokat a forrásokat, ahonnan a böngésző erőforrásokat tölthet be.
• Strict-Transport-Security (HSTS): Kényszeríti a böngészőt, hogy a webhellyel folytatott minden kommunikációhoz HTTPS-t használjon.
• X-Frame-Options: Megakadályozza, hogy a webhelyet iframe-be ágyazzák, csökkentve ezzel a clickjacking támadások kockázatát.
• X-XSS-Protection: Engedélyezi a böngésző beépített XSS-szűrőjét. (Megjegyzés: Gyakran a CSP felülírja, de még mindig nyújthat egy védelmi réteget).
• Referrer-Policy: Szabályozza a kérésekkel küldött referrer információ mennyiségét.
• Feature-Policy (most már Permissions-Policy): Lehetővé teszi a fejlesztők számára, hogy szelektíven engedélyezzék és letiltsák a böngésző funkcióit és API-jait.

Mélyreható betekintés a Content Security Policy-ba (CSP)

A Content Security Policy (CSP) egy HTTP válaszfejléc, amely szabályozza, hogy a felhasználói ügynök (böngésző) milyen erőforrásokat tölthet be egy adott oldalhoz. Lényegében engedélyezőlistára teszi a jóváhagyott tartalmak forrásait, jelentősen csökkentve az XSS támadások kockázatát. Azáltal, hogy explicit módon meghatározza azokat az eredeteket, ahonnan erőforrások, mint például szkriptek, stíluslapok, képek és betűtípusok betölthetők, a CSP sokkal nehezebbé teszi a támadók számára, hogy kártékony kódot juttassanak be a webhelyére.

Hogyan működik a CSP?

A CSP úgy működik, hogy a böngészőnek egy listát ad a jóváhagyott forrásokról a különböző tartalomtípusokhoz. Amikor a böngésző olyan erőforrással találkozik, amely sérti a CSP-t, letiltja az erőforrást és jelenti a sértést. Ez a blokkoló mechanizmus megakadályozza a kártékony kód végrehajtását, még akkor is, ha a támadónak sikerül azt bejuttatnia a HTML-be.

CSP direktívák

A CSP direktívák a CSP házirend alapvető összetevői. Meghatározzák a különböző típusú erőforrások engedélyezett forrásait. Néhány a leggyakrabban használt direktívák közül:

• default-src: Beállítja az alapértelmezett forrást minden erőforrástípushoz. Ez egy visszalépési direktíva, amely akkor érvényesül, ha más, specifikusabb direktívák nincsenek meghatározva.
• script-src: Meghatározza a JavaScript engedélyezett forrásait.
• style-src: Meghatározza a CSS stíluslapok engedélyezett forrásait.
• img-src: Meghatározza a képek engedélyezett forrásait.
• font-src: Meghatározza a betűtípusok engedélyezett forrásait.
• media-src: Meghatározza az audio- és videotartalmak engedélyezett forrásait.
• object-src: Meghatározza a bővítmények, mint például a Flash, engedélyezett forrásait. (Általában a legjobb elkerülni a bővítmények engedélyezését, ha lehetséges).
• frame-src: Meghatározza a keretek (iframe-ek) engedélyezett forrásait.
• connect-src: Meghatározza a hálózati kérések (AJAX, WebSockets) engedélyezett forrásait.
• base-uri: Korlátozza azokat az URL-eket, amelyek egy <base> elemben használhatók.
• form-action: Korlátozza azokat az URL-eket, amelyekre űrlapokat lehet küldeni.
• frame-ancestors: Meghatározza azokat az érvényes szülőket, amelyek beágyazhatnak egy oldalt <frame>, <iframe>, <object>, <embed>, vagy <applet> segítségével. Ez a direktíva védelmet nyújt a Clickjacking ellen.
• upgrade-insecure-requests: Utasítja a felhasználói ügynököket, hogy egy webhely összes nem biztonságos URL-jét (HTTP-n keresztül betöltve) úgy kezeljék, mintha biztonságos URL-ekkel (HTTPS-en keresztül betöltve) lennének helyettesítve. Ez a direktíva olyan webhelyek számára készült, amelyek éppen a HTTP-ről HTTPS-re való átállás folyamatában vannak.
• report-uri: Meghatároz egy URL-t, ahová a böngészőnek jelentéseket kell küldenie a CSP-sértésekről. Elavult, helyette a `report-to` használatos.
• report-to: Meghatároz egy csoportnevet, amely egy `Report-To` fejlécben van definiálva. Ez finomabb vezérlést tesz lehetővé a jelentések felett, beleértve több jelentési végpont megadását is.

CSP forrásértékek

A forrásértékek határozzák meg azokat az eredeteket, ahonnan az erőforrások betöltése engedélyezett. Néhány gyakori forrásérték:

• *: Bármilyen forrásból engedélyezi a tartalmat (Éles környezetben kerülendő!).
• 'self': Engedélyezi a tartalmat a védett dokumentummal azonos eredetből (séma, hoszt és port).
• 'none': Nem engedélyez tartalmat semmilyen forrásból.
• 'unsafe-inline': Engedélyezi a beágyazott JavaScript és CSS használatát (Éles környezetben kerülendő!).
• 'unsafe-eval': Engedélyezi a dinamikus kód kiértékelését (pl. eval(), Function()) (Éles környezetben kerülendő!).
• 'strict-dynamic': Meghatározza, hogy a jelölésben egy szkriptnek explicit módon, nonce vagy hash kíséretében adott bizalmat tovább kell örökíteni az összes olyan szkriptre, amelyet az az ős betölt.
• 'unsafe-hashes': Engedélyezi a specifikus beágyazott eseménykezelőket. Ez általában nem ajánlott a bonyolultsága és korlátozott haszna miatt.
• data:: Engedélyezi az erőforrások betöltését data URL-ekből (pl. beágyazott képek). Óvatosan használja.
• mediastream:: Engedélyezi a `mediastream:` URI-k médiaforrásként való használatát.
• blob:: Engedélyezi a `blob:` URI-k médiaforrásként való használatát.
• filesystem:: Engedélyezi az erőforrások fájlrendszerből történő betöltését.
• https://example.com: Engedélyezi a tartalmat egy adott domainről és portról.
• *.example.com: Engedélyezi a tartalmat az example.com bármely aldomainjéről.
• nonce-{random-value}: Engedélyezi a szkripteket vagy stílusokat, amelyeknek megfelelő nonce attribútumuk van. Ehhez a szerver oldalon minden kéréshez egy véletlenszerű nonce értéket kell generálni.
• sha256-{hash-value}: Engedélyezi a szkripteket vagy stílusokat, amelyeknek megfelelő SHA256, SHA384 vagy SHA512 hash értékük van.

CSP módok: Kényszerítő (Enforce) vs. csak jelentő (Report-Only)

A CSP két módban telepíthető:

• Kényszerítő mód (Enforce Mode): Ebben a módban a böngésző letilt minden olyan erőforrást, amely sérti a CSP-t. Ez az ajánlott mód éles környezetekben. A CSP-t a `Content-Security-Policy` fejléc segítségével küldik.
• Csak jelentő mód (Report-Only Mode): Ebben a módban a böngésző jelenti a CSP-sértéseket, de nem tiltja le az erőforrásokat. Ez hasznos egy CSP teszteléséhez és kiértékeléséhez, mielőtt élesítenék. A CSP-t a `Content-Security-Policy-Report-Only` fejléc segítségével küldik.

A CSP bevezetése: Lépésről lépésre útmutató

A CSP bevezetése ijesztőnek tűnhet, de egy strukturált megközelítéssel hatékonyan biztosíthatja webalkalmazását.

1. Kezdje egy csak jelentő (Report-Only) házirenddel

Kezdje egy CSP telepítésével csak jelentő módban. Ez lehetővé teszi a sértések figyelését anélkül, hogy megzavarná a webhelye működését. Konfigurálja a report-uri vagy report-to direktívát, hogy a sértési jelentéseket egy kijelölt végpontra küldje.

Példa fejléc (Report-Only): Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

2. Elemezze a sértési jelentéseket

Gondosan elemezze a sértési jelentéseket, hogy azonosítsa, mely erőforrások kerülnek letiltásra és miért. Ez segít megérteni webhelye erőforrás-függőségeit és azonosítani a lehetséges biztonsági réseket.

A sértési jelentéseket általában JSON formátumban küldik a konfigurált report-uri vagy report-to végpontra. Ezek a jelentések információkat tartalmaznak a sértésről, például a letiltott URI-t, a megsértett direktívát és a dokumentum URI-ját.

3. Finomítsa a CSP házirendet

A sértési jelentések alapján finomítsa a CSP házirendet, hogy engedélyezze a jogos erőforrásokat, miközben fenntartja az erős biztonsági pozíciót. Adjon hozzá specifikus forrásértékeket a letiltott erőforrásokhoz. Fontolja meg a nonce-ok vagy hash-ek használatát a beágyazott szkriptekhez és stílusokhoz, hogy elkerülje az 'unsafe-inline' használatát.

4. Váltás kényszerítő (Enforce) módra

Amint biztos abban, hogy a CSP házirendje nem tiltja le a jogos erőforrásokat, váltson kényszerítő módra. Ez letiltja a fennmaradó sértéseket, és robusztus védelmi réteget biztosít az XSS támadások ellen.

Példa fejléc (Enforce): Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

5. Figyelje és tartsa karban a CSP házirendet

A CSP nem egy „beállítod és elfelejted” megoldás. Lényeges folyamatosan figyelni a CSP házirendet, és frissíteni azt, ahogy a webhelye fejlődik és új biztonsági fenyegetések jelennek meg. Rendszeresen tekintse át a sértési jelentéseket és szükség szerint módosítsa a házirendet.

Gyakorlati CSP példák

Nézzünk néhány gyakorlati CSP példát különböző forgatókönyvekre:

1. példa: Alapvető CSP egy egyszerű webhelyhez

Ez a CSP engedélyezi a tartalmat az azonos eredetből és a képeket bármilyen forrásból.

Content-Security-Policy: default-src 'self'; img-src *

2. példa: CSP specifikus szkript- és stílusforrásokkal

Ez a CSP engedélyezi a szkripteket az azonos eredetből és egy specifikus CDN-ről, valamint a stílusokat az azonos eredetből és a beágyazott stílusokat.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

3. példa: CSP nonce-okkal a beágyazott szkriptekhez

Ez a CSP egyedi nonce-t igényel minden beágyazott szkripthez.

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mn0nc3'

HTML:

<script nonce="r4nd0mn0nc3">console.log('Hello, world!');</script>

Fontos: A nonce értékét dinamikusan kell generálni a szerveren minden kérésnél. Ez megakadályozza, hogy a támadók újra felhasználják a nonce-t.

4. példa: CSP a frame-ancestors korlátozásával a clickjacking megelőzésére

Ez a CSP megakadályozza, hogy az oldalt beágyazzák egy iframe-be bármely domainen, kivéve a `https://example.com`-ot.

Content-Security-Policy: frame-ancestors 'self' https://example.com

5. példa: Egy szigorúbb CSP 'strict-dynamic' használatával és 'self' visszalépési lehetőséggel

Ez a CSP a `strict-dynamic` előnyeit használja ki a modern böngészőkben, miközben támogatja a régebbi böngészőket is, amelyek ezt nem támogatják. Tartalmaz egy `report-uri`-t is a sértések figyelésére.

Content-Security-Policy: default-src 'self'; script-src 'strict-dynamic' 'nonce-{random-nonce}' 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report

Ne felejtse el a `{random-nonce}`-t egy dinamikusan generált nonce értékkel helyettesíteni a szerver oldalon.

CSP és egyoldalas alkalmazások (SPA-k)

A CSP bevezetése SPA-kban kihívást jelenthet ezeknek az alkalmazásoknak a dinamikus természete miatt. Az SPA-k gyakran nagymértékben támaszkodnak a JavaScriptre a DOM generálásához és manipulálásához, ami CSP-sértésekhez vezethet, ha nem kezelik óvatosan.

Íme néhány tipp a CSP bevezetéséhez SPA-kban:

• Kerülje az 'unsafe-inline' és 'unsafe-eval' használatát: Ezeket a direktívákat lehetőség szerint kerülni kell az SPA-kban. Jelentősen gyengítik az alkalmazás biztonságát.
• Használjon nonce-okat vagy hash-eket: Használjon nonce-okat vagy hash-eket a beágyazott szkriptekhez és stílusokhoz. Ez az ajánlott megközelítés az SPA-k esetében.
• Fontolja meg a Trusted Types használatát: A Trusted Types egy böngésző API, amely segít megelőzni a DOM-alapú XSS sebezhetőségeket. A CSP-vel együtt használva tovább növelheti a biztonságot.
• Használjon CSP-kompatibilis keretrendszert: Néhány frontend keretrendszer (mint például a React specifikus konfigurációkkal, az Angular és a Vue.js) olyan funkciókat kínál, amelyek megkönnyítik a CSP bevezetését.

Más fontos frontend biztonsági fejlécek

Míg a CSP a frontend biztonság sarokköve, más fejlécek is kulcsfontosságú szerepet játszanak egy átfogó védelmi stratégia kialakításában:

Strict-Transport-Security (HSTS)

A Strict-Transport-Security (HSTS) fejléc utasítja a böngészőt, hogy mindig HTTPS-t használjon a webhelyhez való csatlakozáshoz. Ez megakadályozza a közbeékelődéses (man-in-the-middle) támadásokat, amelyek megpróbálják a kapcsolatot HTTP-re lefokozni.

Példa fejléc: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: Meghatározza azt az időtartamot (másodpercben), ameddig a böngészőnek emlékeznie kell arra, hogy a webhelyet csak HTTPS-en keresztül érje el. Éles környezetben 31536000 másodperc (1 év) érték ajánlott.
• includeSubDomains: Azt jelzi, hogy a HSTS házirend a domain összes aldomainjére érvényes.
• preload: Lehetővé teszi, hogy a domain bekerüljön egy HSTS-engedélyezett domainek listájába, amely előre be van töltve a böngészőkbe. Ehhez be kell küldeni a domaint a Google által fenntartott HSTS preload listára.

X-Frame-Options

Az X-Frame-Options fejléc megakadályozza a clickjacking támadásokat azáltal, hogy szabályozza, hogy a webhelyet be lehet-e ágyazni egy iframe-be.

Példa fejléc: X-Frame-Options: DENY

Lehetséges értékek:

• DENY: Megakadályozza, hogy az oldal megjelenjen egy iframe-ben, az eredettől függetlenül.
• SAMEORIGIN: Lehetővé teszi, hogy az oldal megjelenjen egy iframe-ben, de csak akkor, ha az iframe eredete megegyezik az oldal eredetével.
• ALLOW-FROM uri: Lehetővé teszi, hogy az oldal megjelenjen egy iframe-ben, de csak akkor, ha az iframe eredete megegyezik a megadott URI-val. Megjegyzés: Ez az opció elavult, és nem minden böngésző támogatja.

Megjegyzés: A CSP frame-ancestors direktívája rugalmasabb és hatékonyabb módot kínál a keretezés szabályozására, és általában előnyben részesítik az X-Frame-Options-szal szemben.

X-XSS-Protection

Az X-XSS-Protection fejléc engedélyezi a böngésző beépített XSS-szűrőjét. Míg a CSP robusztusabb megoldás az XSS támadások megelőzésére, ez a fejléc további védelmi réteget nyújthat, különösen a régebbi böngészők számára, amelyek esetleg nem támogatják teljes mértékben a CSP-t.

Példa fejléc: X-XSS-Protection: 1; mode=block

• 1: Engedélyezi az XSS-szűrőt.
• 0: Letiltja az XSS-szűrőt.
• mode=block: Utasítja a böngészőt, hogy blokkolja az oldalt, ha XSS támadást észlel.
• report=uri: Meghatároz egy URL-t, ahová a böngészőnek jelentést kell küldenie, ha XSS támadást észlel.

Referrer-Policy

A Referrer-Policy fejléc szabályozza a kérésekkel küldött referrer információ mennyiségét. A referrer információ felhasználható a felhasználók webhelyek közötti követésére, így ennek szabályozása javíthatja a felhasználói adatvédelmet.

Példa fejléc: Referrer-Policy: strict-origin-when-cross-origin

Néhány gyakori érték:

• no-referrer: Soha ne küldje el a Referer fejlécet.
• no-referrer-when-downgrade: Ne küldje el a Referer fejlécet TLS (HTTPS) nélküli eredeteknek.
• origin: Csak az eredetet (séma, hoszt és port) küldje el a Referer fejlécben.
• origin-when-cross-origin: Küldje az eredetet a cross-origin kérésekhez, és a teljes URL-t az azonos eredetű kérésekhez.
• same-origin: Küldje a Referer fejlécet az azonos eredetű kérésekhez, de ne a cross-origin kérésekhez.
• strict-origin: Csak az eredetet küldje el, ha a protokoll biztonsági szintje ugyanaz marad (HTTPS-ről HTTPS-re), de ne küldjön fejlécet egy kevésbé biztonságos célállomásra (HTTPS-ről HTTP-re).
• strict-origin-when-cross-origin: Azonos eredetű kérés esetén küldje el az eredetet. Kereszt-eredetű kérések esetén csak akkor küldje el az eredetet, ha a protokoll biztonsági szintje ugyanaz marad (HTTPS-ről HTTPS-re), de ne küldjön fejlécet egy kevésbé biztonságos célállomásra (HTTPS-ről HTTP-re).
• unsafe-url: Küldje el a teljes URL-t a Referer fejlécben, az eredettől függetlenül. Különös óvatossággal használja, mert érzékeny információkat tehet közzé.

Permissions-Policy (korábban Feature-Policy)

A Permissions-Policy fejléc (korábban Feature-Policy néven ismert) lehetővé teszi a fejlesztők számára, hogy szelektíven engedélyezzék és letiltsák a böngésző funkcióit és API-jait. Ez segíthet csökkenteni az alkalmazás támadási felületét és javítani a felhasználói adatvédelmet.

Példa fejléc: Permissions-Policy: geolocation=()

Ez a példa letiltja a geolocation API-t a webhelyen.

Más funkciók, amelyeket a Permissions-Policy-val lehet szabályozni:

• camera
• microphone
• geolocation
• accelerometer
• gyroscope
• magnetometer
• usb
• midi
• payment
• fullscreen

Biztonsági fejlécek beállítása különböző platformokon

A biztonsági fejlécek beállításának módja a használt webszervertől vagy platformtól függ. Íme néhány gyakori példa:

Apache

Az Apache-ban a biztonsági fejléceket a .htaccess fájlhoz vagy a szerver konfigurációs fájljához (httpd.conf) való hozzáadással állíthatja be.

Példa .htaccess konfiguráció:

<IfModule mod_headers.c>
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report"
 Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
 Header set X-Frame-Options "DENY"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Nginx

Az Nginx-ben a biztonsági fejléceket az Nginx konfigurációs fájljának (nginx.conf) szerver blokkjához való hozzáadással állíthatja be.

Példa Nginx konfiguráció:

server {
 listen 443 ssl;
 server_name example.com;

 add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-uri /csp-report";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
 add_header X-Frame-Options "DENY";
 add_header X-XSS-Protection "1; mode=block";
 add_header Referrer-Policy "strict-origin-when-cross-origin";

 ...
}

Node.js (Express)

A Node.js-ben a biztonsági fejléceket middleware, például a Helmet segítségével állíthatja be.

Példa a Helmet használatával:

const express = require('express');
const helmet = require('helmet');

const app = express();

app.use(helmet());

// A CSP testreszabása szükség esetén
app.use(helmet.contentSecurityPolicy({
 directives: {
 defaultSrc: ["'self'"],
 scriptSrc: ["'self'", "https://cdn.example.com"],
 styleSrc: ["'self'", "'unsafe-inline'"],
 imgSrc: ["'self'", "data:"],
 reportUri: '/csp-report'
 },
}));

app.get('/', (req, res) => {
 res.send('Hello World!');
});

app.listen(3000, () => {
 console.log('Server listening on port 3000');
});

Cloudflare

A Cloudflare lehetővé teszi a biztonsági fejlécek beállítását a Page Rules vagy a Transform Rules segítségével.

A biztonsági fejlécek tesztelése

A biztonsági fejlécek bevezetése után elengedhetetlen azok tesztelése, hogy megbizonyosodjon a helyes működésükről. Számos online eszköz segíthet a webhely biztonsági fejléceinek elemzésében:

• SecurityHeaders.com: Egy egyszerű és hatékony eszköz a biztonsági fejlécek elemzéséhez.
• Mozilla Observatory: Egy átfogó eszköz a webhelyek biztonságának tesztelésére, beleértve a biztonsági fejléceket is.
• WebPageTest.org: Lehetővé teszi a HTTP fejlécek megtekintését a vízesés diagramban.

Összegzés

A frontend biztonsági fejlécek, különösen a Content Security Policy (CSP), elengedhetetlenek a webalkalmazások különböző támadások elleni védelméhez és a felhasználói biztonság növeléséhez. Ezen fejlécek gondos bevezetésével és karbantartásával jelentősen csökkentheti az XSS, a clickjacking és más biztonsági sebezhetőségek kockázatát. Ne felejtse el egy csak jelentő házirenddel kezdeni, elemezni a sértési jelentéseket, finomítani a házirendet, majd áttérni a kényszerítő módra. Rendszeresen figyelje és frissítse a biztonsági fejléceket, hogy webhelye biztonságos maradjon, ahogy fejlődik és új fenyegetések jelennek meg.

A frontend biztonság proaktív megközelítésével biztonságosabb és megbízhatóbb webalkalmazásokat hozhat létre, amelyek védik a felhasználókat és a vállalkozását.