Frontend biztonság megerősítése: Content Security Policy és CORS

Napjaink összekapcsolt digitális világában a frontend biztonság kiemelkedően fontos. A webalkalmazásokat egyre inkább kifinomult támadások érik, ami elengedhetetlenné teszi a robusztus biztonsági intézkedéseket. A biztonságos frontend architektúra két kritikus eleme a Content Security Policy (CSP) és a Cross-Origin Resource Sharing (CORS). Ez az átfogó útmutató mélyrehatóan bemutatja ezeket a technológiákat, gyakorlati példákat és hasznosítható ismereteket nyújtva, hogy megerősíthesse webalkalmazásait a modern fenyegetésekkel szemben.

Mi az a Content Security Policy (CSP)?

A Content Security Policy (CSP) egy további biztonsági réteg, amely segít bizonyos típusú támadások, többek között a Cross-Site Scripting (XSS) és az adatbefecskendezéses támadások észlelésében és enyhítésében. A CSP-t a webszerver valósítja meg egy Content-Security-Policy HTTP válaszfejléc böngészőnek való elküldésével. Ez a fejléc meghatározza azon források fehérlistáját, amelyekből a böngésző számára engedélyezett az erőforrások betöltése. Azáltal, hogy korlátozza a böngésző által betölthető tartalmak forrásait, a CSP jelentősen megnehezíti a támadók számára, hogy rosszindulatú kódot juttassanak be a webhelyére.

Hogyan működik a CSP

A CSP úgy működik, hogy utasítja a böngészőt, hogy csak jóváhagyott forrásokból töltsön be erőforrásokat (pl. szkripteket, stíluslapokat, képeket, betűtípusokat). Ezeket a forrásokat a CSP fejlécben direktívák segítségével adják meg. Ha egy böngésző olyan forrásból próbál meg betölteni egy erőforrást, amely nincs kifejezetten engedélyezve, letiltja a kérést és szabálysértést jelent.

CSP direktívák: Átfogó áttekintés

A CSP direktívák szabályozzák, hogy milyen típusú erőforrások tölthetők be adott forrásokból. Íme egy áttekintés a legfontosabb direktívákról:

• default-src: Meghatározza az alapértelmezett forrást minden tartalomtípushoz. Ez egy tartalék direktíva, amely akkor érvényesül, ha más, specifikusabb direktívák nincsenek jelen.
• script-src: Meghatározza azokat a forrásokat, ahonnan szkriptek tölthetők be. Ez kulcsfontosságú az XSS támadások megelőzésében.
• style-src: Meghatározza azokat a forrásokat, ahonnan stíluslapok tölthetők be.
• img-src: Meghatározza azokat a forrásokat, ahonnan képek tölthetők be.
• font-src: Meghatározza azokat a forrásokat, ahonnan betűtípusok tölthetők be.
• media-src: Meghatározza azokat a forrásokat, ahonnan hang- és videóanyagok tölthetők be.
• object-src: Meghatározza azokat a forrásokat, ahonnan bővítmények (pl. Flash) tölthetők be. Ezt gyakran 'none'-ra állítják a bővítmények teljes letiltása érdekében, azok eredendő biztonsági kockázatai miatt.
• frame-src: Meghatározza azokat a forrásokat, ahonnan keretek (pl. <iframe>) tölthetők be.
• connect-src: Meghatározza azokat az URL-eket, amelyekhez a felhasználói ügynök csatlakozhat szkript interfészeken keresztül, mint például az XMLHttpRequest, WebSocket és EventSource.
• base-uri: Meghatározza azokat az URL-eket, amelyek egy dokumentum <base> elemében használhatók.
• form-action: Meghatározza azokat az URL-eket, amelyekre űrlapküldések küldhetők.
• upgrade-insecure-requests: Utasítja a felhasználói ügynököt, hogy a nem biztonságos kéréseket (HTTP) automatikusan frissítse biztonságos kérésekre (HTTPS).
• report-uri: Meghatároz egy URL-t, ahová a böngészőnek jelentéseket kell küldenie a CSP megsértéseiről. Ez a direktíva elavult a `report-to` javára.
• report-to: Meghatároz egy, a `Report-To` fejlécben definiált jelentési csoportnevet, ahová a böngészőnek jelentéseket kell küldenie a CSP megsértéseiről.

CSP forráslista kulcsszavak

A CSP direktívákon belül forráslista kulcsszavakat használhat az engedélyezett források meghatározásához. Íme néhány gyakori kulcsszó:

• 'self': Engedélyezi az erőforrásokat a dokumentummal azonos eredetről (séma és hoszt).
• 'none': Letiltja az erőforrásokat minden forrásból.
• 'unsafe-inline': Engedélyezi az inline szkriptek és stílusok használatát (pl. <script> tagek és style attribútumok). Rendkívüli óvatossággal használja, mivel jelentősen gyengíti a CSP védelmét az XSS ellen.
• 'unsafe-eval': Engedélyezi a dinamikus kódkiértékelő függvények, mint a eval() és a Function() használatát. Rendkívüli óvatossággal használja, mivel jelentős biztonsági kockázatokat rejt.
• 'unsafe-hashes': Engedélyezi a megadott hash-nek megfelelő specifikus inline eseménykezelőket vagy <style> tageket. Böngészőtámogatást igényel. Óvatosan használja.
• 'strict-dynamic': Meghatározza, hogy a jelölésben található szkriptnek nonce-szal vagy hash-sel történő explicit bizalomadását tovább kell örökíteni az adott gyökérszkript által betöltött összes szkriptre.
• data: Engedélyezi a data: URI-kat (pl. base64 kódolású inline képek). Óvatosan használja.
• https:: Lehetővé teszi az erőforrások betöltését HTTPS-en keresztül bármely domainről.
• [hostname]: Engedélyezi az erőforrásokat egy adott domainről (pl. example.com). Megadhat portszámot is (pl. example.com:8080).
• [scheme]://[hostname]:[port]: Egy teljes URI, amely engedélyezi az erőforrásokat a megadott sémáról, hosztról és portról.

Gyakorlati CSP példák

Nézzünk néhány gyakorlati példát a CSP fejlécekre:

1. példa: Alapvető CSP 'self'-fel

Ez a szabályzat csak az azonos eredetű erőforrásokat engedélyezi:

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

2. példa: Szkriptek engedélyezése egy adott domainről

Ez a szabályzat engedélyezi a szkripteket a saját domainjéről és egy megbízható CDN-ről:

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

              
                Copy
              
            
          

3. példa: Inline szkriptek és stílusok letiltása

Ez a szabályzat letiltja az inline szkripteket és stílusokat, ami erős védelem az XSS ellen:

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

Fontos: Az inline szkriptek letiltása megköveteli a HTML refaktorálását, hogy az inline szkripteket külső fájlokba helyezze át.

4. példa: Nonce-ok használata inline szkriptekhez

Ha inline szkripteket kell használnia, használjon nonce-okat (kriptográfiailag véletlenszerű, egyszer használatos tokeneket) bizonyos inline szkriptblokkok engedélyezéséhez. Ez biztonságosabb, mint az 'unsafe-inline'. A szervernek minden kéréshez egyedi nonce-t kell generálnia, és azt mind a CSP fejlécbe, mind a <script> tagbe be kell foglalnia.

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

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

Megjegyzés: Ne felejtsen el minden kéréshez új nonce-t generálni. Ne használja újra a nonce-okat!

5. példa: Hash-ek használata inline stílusokhoz

A nonce-okhoz hasonlóan a hash-ek is használhatók bizonyos inline <style> blokkok engedélyezéséhez. Ez a stílustartalom SHA256, SHA384 vagy SHA512 hash-ének generálásával történik.

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

Megjegyzés: A hash-ek kevésbé rugalmasak, mint a nonce-ok, mivel a stílustartalom bármilyen változása érvényteleníti a hash-t.

6. példa: CSP sértések jelentése

A CSP sértések figyeléséhez használja a report-uri vagy a report-to direktívát:

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Szüksége lesz a Report-To fejléc konfigurálására is. A Report-To fejléc egy vagy több jelentési csoportot határoz meg, amelyek megadják, hogy a jelentéseket hova és hogyan kell küldeni.

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

CSP tesztelése és telepítése

A CSP bevezetése gondos tervezést és tesztelést igényel. Kezdjen egy korlátozó szabályzattal, és fokozatosan lazítsa azt szükség szerint. Használja a Content-Security-Policy-Report-Only fejlécet a szabályzat teszteléséhez anélkül, hogy blokkolná az erőforrásokat. Ez a fejléc jelenti a sértéseket anélkül, hogy érvényesítené a szabályzatot, lehetővé téve a problémák azonosítását és javítását a szabályzat éles környezetben történő telepítése előtt.

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

Elemezze a böngésző által generált jelentéseket a sértések azonosításához, és ennek megfelelően módosítsa a szabályzatát. Miután meggyőződött arról, hogy a szabályzata megfelelően működik, telepítse azt a Content-Security-Policy fejléc használatával.

CSP legjobb gyakorlatok

• Kezdje egy default-src-vel: Mindig határozzon meg egy default-src-t egy alapvető szabályzat létrehozásához.
• Legyen specifikus: Használjon specifikus direktívákat és forráslista kulcsszavakat a szabályzat hatókörének korlátozására.
• Kerülje az 'unsafe-inline' és 'unsafe-eval' használatát: Ezek a kulcsszavak jelentősen gyengítik a CSP-t, és lehetőség szerint kerülni kell őket.
• Használjon nonce-okat vagy hash-eket az inline szkriptekhez és stílusokhoz: Ha inline szkripteket vagy stílusokat kell használnia, használjon nonce-okat vagy hash-eket a specifikus kódblokkok engedélyezéséhez.
• Figyelje a CSP sértéseket: Használja a report-uri vagy report-to direktívát a CSP sértések figyelésére és a szabályzat ennek megfelelő módosítására.
• Teszteljen alaposan: Használja a Content-Security-Policy-Report-Only fejlécet a szabályzat tesztelésére, mielőtt éles környezetben telepítené.
• Iteráljon és finomítson: A CSP nem egyszeri konfiguráció. Folyamatosan figyelje és finomítsa a szabályzatát, hogy alkalmazkodjon az alkalmazásában és a fenyegetési környezetben bekövetkező változásokhoz.

Mi az a Cross-Origin Resource Sharing (CORS)?

A Cross-Origin Resource Sharing (CORS) egy olyan mechanizmus, amely lehetővé teszi, hogy egy weboldal egy adott eredetből (domainből) hozzáférjen egy másik eredetű erőforrásokhoz. Alapértelmezés szerint a böngészők egy Azonos Eredet Szabályt (Same-Origin Policy) érvényesítenek, amely megakadályozza, hogy a szkriptek kéréseket intézzenek egy másik eredethez, mint ahonnan a szkript származik. A CORS lehetőséget biztosít e korlátozás szelektív enyhítésére, lehetővé téve a jogos eredetközi kéréseket, miközben véd a rosszindulatú támadások ellen.

Az Azonos Eredet Szabály (Same-Origin Policy) megértése

Az Azonos Eredet Szabály egy alapvető biztonsági mechanizmus, amely megakadályozza, hogy egy rosszindulatú szkript egy webhelyről hozzáférjen egy másik webhely érzékeny adataihoz. Egy eredetet a séma (protokoll), a hoszt (domain) és a port határoz meg. Két URL akkor azonos eredetű, ha és csak ha azonos a sémájuk, hosztjuk és portjuk.

Például:

• https://www.example.com/app1/index.html és https://www.example.com/app2/index.html azonos eredetűek.
• https://www.example.com/index.html és http://www.example.com/index.html különböző eredetűek (eltérő séma).
• https://www.example.com/index.html és https://sub.example.com/index.html különböző eredetűek (eltérő hoszt).
• https://www.example.com:8080/index.html és https://www.example.com:80/index.html különböző eredetűek (eltérő port).

Hogyan működik a CORS

Amikor egy weboldal eredetközi kérést intéz, a böngésző először egy "preflight" kérést küld a szervernek. A preflight kérés a HTTP OPTIONS metódust használja, és olyan fejléceket tartalmaz, amelyek jelzik a tényleges kérés által használt HTTP metódust és fejléceket. A szerver ezután olyan fejlécekkel válaszol, amelyek jelzik, hogy az eredetközi kérés engedélyezett-e.

Ha a szerver engedélyezi a kérést, a válaszban szerepelteti az Access-Control-Allow-Origin fejlécet. Ez a fejléc meghatározza az(oka)t az eredet(ek)et, amelyek hozzáférhetnek az erőforráshoz. A böngésző ezután folytatja a tényleges kérést. Ha a szerver nem engedélyezi a kérést, nem szerepelteti az Access-Control-Allow-Origin fejlécet, és a böngésző letiltja a kérést.

CORS fejlécek: Részletes áttekintés

A CORS HTTP fejlécekre támaszkodik a böngésző és a szerver közötti kommunikációhoz. Íme a legfontosabb CORS fejlécek:

• Access-Control-Allow-Origin: Meghatározza az(oka)t az eredet(ek)et, amelyek hozzáférhetnek az erőforráshoz. Ez a fejléc tartalmazhat egy konkrét eredetet (pl. https://www.example.com), egy helyettesítő karaktert (*), vagy null-t. A * használata bármely eredetből származó kérést engedélyez, ami biztonsági okokból általában nem ajánlott. A `null` használata csak "átlátszatlan válaszok" esetén helyénvaló, például amikor az erőforrást a `file://` protokollal vagy egy data URI-val hívják le.
• Access-Control-Allow-Methods: Meghatározza az eredetközi kéréshez engedélyezett HTTP metódusokat (pl. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Meghatározza az eredetközi kérésben engedélyezett HTTP fejléceket. Ez fontos az egyedi fejlécek kezeléséhez.
• Access-Control-Allow-Credentials: Jelzi, hogy a böngészőnek tartalmaznia kell-e hitelesítő adatokat (pl. sütiket, engedélyezési fejléceket) az eredetközi kérésben. Ennek a fejlécnek true-ra kell állítva lennie a hitelesítő adatok engedélyezéséhez.
• Access-Control-Expose-Headers: Meghatározza, mely fejlécek tehetők elérhetővé a kliens számára. Alapértelmezés szerint csak korlátozott számú fejléc érhető el.
• Access-Control-Max-Age: Meghatározza a maximális időtartamot (másodpercekben), ameddig a böngésző gyorsítótárazhatja a preflight kérést.
• Origin: Ez egy kérés fejléc, amelyet a böngésző küld, hogy jelezze a kérés eredetét.
• Vary: Egy általános HTTP fejléc, de fontos a CORS szempontjából. Amikor az `Access-Control-Allow-Origin` dinamikusan generálódik, a `Vary: Origin` fejlécet bele kell foglalni a válaszba, hogy utasítsa a gyorsítótárazási mechanizmusokat, hogy a válasz az `Origin` kérés fejléc alapján változik.

Gyakorlati CORS példák

Nézzünk néhány gyakorlati példát a CORS konfigurációkra:

1. példa: Kérések engedélyezése egy adott eredetből

Ez a konfiguráció csak a https://www.example.com-ról érkező kéréseket engedélyezi:

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

2. példa: Kérések engedélyezése bármely eredetből (Nem ajánlott)

Ez a konfiguráció bármely eredetből érkező kérést engedélyez. Óvatosan használja, mivel biztonsági kockázatokat rejthet:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

3. példa: Specifikus metódusok és fejlécek engedélyezése

Ez a konfiguráció engedélyezi a GET, POST és PUT metódusokat, valamint a Content-Type és Authorization fejléceket:

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

4. példa: Hitelesítő adatok engedélyezése

A hitelesítő adatok (pl. sütik) engedélyezéséhez az Access-Control-Allow-Credentials-t true-ra kell állítani, és egy konkrét eredetet kell megadni (nem használhat *-t a hitelesítő adatok engedélyezésekor):

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

A JavaScript fetch/XMLHttpRequest kérésében is be kell állítania a credentials: 'include'-t.

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

CORS preflight kérések

Bizonyos típusú eredetközi kérések esetén (pl. egyedi fejlécekkel vagy a GET, HEAD, vagy POST-tól eltérő metódusokkal, amelyek Content-Type-ja application/x-www-form-urlencoded, multipart/form-data, vagy text/plain), a böngésző egy preflight kérést küld az OPTIONS metódussal. A szervernek válaszolnia kell a preflight kérésre a megfelelő CORS fejlécekkel, hogy jelezze, a tényleges kérés engedélyezett-e.

Íme egy példa egy preflight kérésre és válaszra:

Preflight kérés (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

Preflight válasz (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Az Access-Control-Max-Age fejléc meghatározza, mennyi ideig gyorsítótárazhatja a böngésző a preflight választ, csökkentve ezzel a preflight kérések számát.

CORS és JSONP

A JSON with Padding (JSONP) egy régebbi technika az Azonos Eredet Szabály megkerülésére. Azonban a JSONP jelentős biztonsági kockázatokkal jár, és helyette a CORS használata javasolt. A JSONP <script> tagek oldalba injektálásán alapul, ami tetszőleges kódot futtathat. A CORS biztonságosabb és rugalmasabb módot kínál az eredetközi kérések kezelésére.

CORS legjobb gyakorlatok

• Kerülje a * használatát: Kerülje a helyettesítő karakter (*) használatát az Access-Control-Allow-Origin fejlécben, mivel ez bármely eredetből érkező kérést engedélyez. Ehelyett adja meg az(oka)t a konkrét eredet(ek)et, amelyek hozzáférhetnek az erőforráshoz.
• Legyen specifikus a metódusokkal és fejlécekkel: Adja meg pontosan azokat a HTTP metódusokat és fejléceket, amelyek engedélyezettek az Access-Control-Allow-Methods és Access-Control-Allow-Headers fejlécekben.
• Használja az Access-Control-Allow-Credentials-t óvatosan: Csak akkor engedélyezze az Access-Control-Allow-Credentials-t, ha hitelesítő adatokat (pl. sütiket) kell engedélyeznie az eredetközi kérésekben. Legyen tisztában a hitelesítő adatok engedélyezésének biztonsági következményeivel.
• Biztosítsa a preflight kéréseit: Győződjön meg arról, hogy a szervere megfelelően kezeli a preflight kéréseket, és a megfelelő CORS fejléceket adja vissza.
• Használjon HTTPS-t: Mindig használjon HTTPS-t mind az eredethez, mind az eredetközi erőforrásokhoz. Ez segít a közbeékelődéses támadások (man-in-the-middle attacks) elleni védelemben.
• Vary: Origin: Ha dinamikusan generálja az `Access-Control-Allow-Origin` fejlécet, mindig tartalmazza a `Vary: Origin` fejlécet a gyorsítótárazási problémák elkerülése érdekében.

CSP és CORS a gyakorlatban: Kombinált megközelítés

Bár a CSP és a CORS is biztonsági kérdésekkel foglalkozik, különböző rétegeken működnek és kiegészítő védelmet nyújtanak. A CSP arra összpontosít, hogy megakadályozza a böngészőt a rosszindulatú tartalmak betöltésében, míg a CORS azt szabályozza, hogy mely eredetek férhetnek hozzá a szerverén lévő erőforrásokhoz.

A CSP és a CORS kombinálásával robusztusabb biztonsági helyzetet teremthet webalkalmazásai számára. Például használhatja a CSP-t a szkriptek betöltési forrásainak korlátozására, és a CORS-t az API végpontjaihoz való hozzáférés szabályozására.

Példa: API biztosítása CSP-vel és CORS-szal

Tegyük fel, hogy van egy API-ja a https://api.example.com címen, amelyet csak a https://www.example.com-ról szeretne elérhetővé tenni. Beállíthatja a szerverét, hogy a következő fejléceket adja vissza:

API válaszfejlécek (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

És beállíthatja a webhelyét (https://www.example.com), hogy a következő CSP fejlécet használja:

Weboldal CSP fejléce (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

Ez a CSP szabályzat lehetővé teszi a webhely számára, hogy szkripteket töltsön be és csatlakozzon az API-hoz, de megakadályozza, hogy más domainekről töltsön be szkripteket vagy csatlakozzon hozzájuk.

Összegzés

A Content Security Policy (CSP) és a Cross-Origin Resource Sharing (CORS) elengedhetetlen eszközök a frontend alkalmazások biztonságának megerősítéséhez. A CSP és a CORS gondos konfigurálásával jelentősen csökkentheti az XSS támadások, az adatbefecskendezéses támadások és más biztonsági sebezhetőségek kockázatát. Ne felejtse el egy korlátozó szabályzattal kezdeni, alaposan tesztelni, és folyamatosan figyelni és finomítani a konfigurációját, hogy alkalmazkodjon az alkalmazásában és a fejlődő fenyegetési környezetben bekövetkező változásokhoz. A frontend biztonság előtérbe helyezésével megvédheti felhasználóit és biztosíthatja webalkalmazásai integritását napjaink egyre összetettebb digitális világában.