Esirakenduse turvalisuse tugevdamine: sisuturbe poliitika ja CORS

Tänapäeva omavahel ühendatud digitaalses maailmas on esirakenduse turvalisus esmatähtis. Veebirakendused on üha sagedamini keerukate rünnakute sihtmärgiks, mistõttu on tugevad turvameetmed hädavajalikud. Kaks kriitilist komponenti turvalises esirakenduse arhitektuuris on sisuturbe poliitika (Content Security Policy, CSP) ja päritoluülene ressursijagamine (Cross-Origin Resource Sharing, CORS). See põhjalik juhend annab sügava ülevaate nendest tehnoloogiatest, pakkudes praktilisi näiteid ja rakendatavaid teadmisi, mis aitavad teil oma veebirakendusi kaasaegsete ohtude eest kaitsta.

Mis on sisuturbe poliitika (CSP)?

Sisuturbe poliitika (CSP) on täiendav turvakiht, mis aitab tuvastada ja leevendada teatud tüüpi rünnakuid, sealhulgas saidiülest skriptimist (Cross-Site Scripting, XSS) ja andmesisestusrünnakuid. CSP rakendatakse veebiserveri poolt, saates brauserile Content-Security-Policy HTTP vastusepäise. See päis määratleb lubatud allikate nimekirja, kust brauseril on lubatud ressursse laadida. Piirates sisuallikaid, mida brauser saab laadida, muudab CSP ründajatel pahatahtliku koodi teie veebisaidile sisestamise oluliselt keerulisemaks.

Kuidas CSP töötab

CSP toimib, andes brauserile korralduse laadida ressursse (nt skripte, stiililehti, pilte, fonte) ainult heakskiidetud allikatest. Need allikad on määratud CSP päises direktiivide abil. Kui brauser üritab laadida ressurssi allikast, mis pole selgesõnaliselt lubatud, blokeerib ta päringu ja teatab rikkumisest.

CSP direktiivid: põhjalik ülevaade

CSP direktiivid kontrollivad, milliseid tüüpi ressursse saab kindlatest allikatest laadida. Siin on ülevaade mõnest kõige olulisemast direktiivist:

• default-src: Määrab vaikimisi allika kõikidele sisutüüpidele. See on tagavaradirektiiv, mis rakendub siis, kui teised, spetsiifilisemad direktiivid puuduvad.
• script-src: Määrab allikad, kust skripte saab laadida. See on XSS-rünnakute ennetamisel ülioluline.
• style-src: Määrab allikad, kust stiililehti saab laadida.
• img-src: Määrab allikad, kust pilte saab laadida.
• font-src: Määrab allikad, kust fonte saab laadida.
• media-src: Määrab allikad, kust heli ja videot saab laadida.
• object-src: Määrab allikad, kust pistikprogramme (nt Flash) saab laadida. See on sageli seatud väärtusele 'none', et keelata pistikprogrammid nende olemuslike turvariskide tõttu täielikult.
• frame-src: Määrab allikad, kust raame (nt <iframe>) saab laadida.
• connect-src: Määrab URL-id, millega kasutajaagent saab ühendust luua skriptiliideste kaudu, nagu XMLHttpRequest, WebSocket ja EventSource.
• base-uri: Määrab URL-id, mida saab kasutada dokumendi <base> elemendis.
• form-action: Määrab URL-id, kuhu vormide esitamisi saab saata.
• upgrade-insecure-requests: Annab kasutajaagendile korralduse uuendada ebaturvalised päringud (HTTP) automaatselt turvalisteks päringuteks (HTTPS).
• report-uri: Määrab URL-i, kuhu brauser peaks saatma aruandeid CSP rikkumiste kohta. See direktiiv on aegunud ja eelistatud on `report-to`.
• report-to: Määrab `Report-To` päises määratletud aruandlusgrupi nime, kuhu brauser peaks saatma aruandeid CSP rikkumiste kohta.

CSP allikate loendi märksõnad

CSP direktiivides saate kasutada allikate loendi märksõnu lubatud allikate määratlemiseks. Siin on mõned levinumad märksõnad:

• 'self': Lubab ressursse samast päritolust (skeem ja host) kui dokument.
• 'none': Keelab ressursid kõikidest allikatest.
• 'unsafe-inline': Lubab kasutada tekstisiseseid skripte ja stiile (nt <script> sildid ja stiiliatribuudid). Kasutage äärmise ettevaatusega, kuna see nõrgendab oluliselt CSP kaitset XSS-i vastu.
• 'unsafe-eval': Lubab kasutada dünaamilise koodi hindamise funktsioone nagu eval() ja Function(). Kasutage äärmise ettevaatusega, kuna see toob kaasa olulisi turvariske.
• 'unsafe-hashes': Lubab spetsiifilisi tekstisiseseid sündmuste käsitlejaid või <style> silte, mis vastavad määratud räsi väärtusele. Nõuab brauseri tuge. Kasutage ettevaatusega.
• 'strict-dynamic': Määrab, et usaldus, mis on selgesõnaliselt antud märgistuses olevale skriptile nonce'i või räsi abil, laieneb kõikidele skriptidele, mille see juurskript laadib.
• data: Lubab data: URI-sid (nt tekstisisesed base64-kodeeritud pildid). Kasutage ettevaatusega.
• https:: Lubab ressursside laadimist HTTPS-i kaudu mis tahes domeenilt.
• [hostname]: Lubab ressursse konkreetselt domeenilt (nt example.com). Saate määrata myös pordinumbri (nt example.com:8080).
• [scheme]://[hostname]:[port]: Täielikult kvalifitseeritud URI, mis lubab ressursse määratud skeemist, hostist ja pordist.

Praktilised CSP näited

Vaatame mõningaid praktilisi näiteid CSP päistest:

Näide 1: Põhiline CSP 'self' abil

See poliitika lubab ressursse ainult samast päritolust:

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

              
                Copy
              
            
          

Näide 2: Skriptide lubamine konkreetselt domeenilt

See poliitika lubab skripte teie enda domeenilt ja usaldusväärsest CDN-ist:

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

              
                Copy
              
            
          

Näide 3: Tekstisiseste skriptide ja stiilide keelamine

See poliitika keelab tekstisisesed skriptid ja stiilid, mis on tugev kaitse XSS-i vastu:

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

              
                Copy
              
            
          

Tähtis: Tekstisiseste skriptide keelamine nõuab teie HTML-i ümbertegemist, et liigutada tekstisisesed skriptid välistesse failidesse.

Näide 4: Nonce'ide kasutamine tekstisiseste skriptide jaoks

Kui peate kasutama tekstisiseseid skripte, kasutage nonce'e (krüptograafiliselt juhuslikke, ühekordselt kasutatavaid tunnuseid), et lubada konkreetseid tekstisiseseid skriptiplokke. See on turvalisem kui 'unsafe-inline'. Server peab iga päringu jaoks genereerima unikaalse nonce'i ja lisama selle nii CSP päisesse kui ka <script> silti.

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

              
                Copy
              
            
          

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

              
                Copy
              
            
          

Märkus: Ärge unustage iga päringu jaoks uut nonce'i genereerida. Ärge taaskasutage nonce'e!

Näide 5: Räsiväärtuste kasutamine tekstisiseste stiilide jaoks

Sarnaselt nonce'idele saab räsiväärtusi kasutada konkreetsete tekstisiseste <style> plokkide lubamiseks. Selleks genereeritakse stiili sisu SHA256, SHA384 või SHA512 räsiväärtus.

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

              
                Copy
              
            
          

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

              
                Copy
              
            
          

Märkus: Räsiväärtused on vähem paindlikud kui nonce'id, kuna iga muudatus stiili sisus muudab räsi kehtetuks.

Näide 6: CSP rikkumistest teavitamine

CSP rikkumiste jälgimiseks kasutage report-uri või report-to direktiivi:

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

              
                Copy
              
            
          

Samuti peate konfigureerima Report-To päise. Report-To päis määratleb ühe või mitu aruandlusgruppi, mis määravad, kuhu ja kuidas aruandeid tuleks saata.

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

              
                Copy
              
            
          

CSP testimine ja rakendamine

CSP rakendamine nõuab hoolikat planeerimist ja testimist. Alustage piirava poliitikaga ja leevendage seda järk-järgult vastavalt vajadusele. Kasutage Content-Security-Policy-Report-Only päist, et testida oma poliitikat ilma ressursse blokeerimata. See päis teatab rikkumistest ilma poliitikat jõustamata, võimaldades teil tuvastada ja parandada probleeme enne poliitika tootmiskeskkonda viimist.

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

              
                Copy
              
            
          

Analüüsige brauseri genereeritud aruandeid, et tuvastada rikkumisi ja kohandada oma poliitikat vastavalt. Kui olete kindel, et teie poliitika töötab õigesti, rakendage see kasutades Content-Security-Policy päist.

CSP parimad praktikad

• Alustage default-src-ga: Määratlege alati default-src, et luua baaspoliitika.
• Olge spetsiifiline: Kasutage spetsiifilisi direktiive ja allikate loendi märksõnu, et piirata oma poliitika ulatust.
• Vältige 'unsafe-inline' ja 'unsafe-eval': Need märksõnad nõrgendavad oluliselt CSP-d ja neid tuleks võimalusel vältida.
• Kasutage nonce'e või räsiväärtusi tekstisiseste skriptide ja stiilide jaoks: Kui peate kasutama tekstisiseseid skripte või stiile, kasutage nonce'e või räsiväärtusi konkreetsete koodiplokkide lubamiseks.
• Jälgige CSP rikkumisi: Kasutage report-uri või report-to direktiivi, et jälgida CSP rikkumisi ja kohandada oma poliitikat vastavalt.
• Testige põhjalikult: Kasutage Content-Security-Policy-Report-Only päist, et testida oma poliitikat enne selle tootmiskeskkonda viimist.
• Itereerige ja täiustage: CSP ei ole ühekordne seadistus. Jälgige ja täiustage pidevalt oma poliitikat, et kohaneda muutustega teie rakenduses ja ohtude maastikul.

Mis on päritoluülene ressursijagamine (CORS)?

Päritoluülene ressursijagamine (CORS) on mehhanism, mis võimaldab ühe päritoluga (domeeniga) veebilehtedel pääseda juurde ressurssidele teisest päritolust. Vaikimisi rakendavad brauserid sama päritolu poliitikat (Same-Origin Policy), mis takistab skriptidel teha päringuid teise päritoluga serverisse kui see, kust skript pärineb. CORS pakub võimalust seda piirangut valikuliselt leevendada, lubades seaduslikke päritoluüleseid päringuid, kaitstes samal ajal pahatahtlike rünnakute eest.

Sama päritolu poliitika mõistmine

Sama päritolu poliitika on fundamentaalne turvamehhanism, mis takistab pahatahtlikul skriptil ühel veebisaidil juurdepääsu tundlikele andmetele teisel veebisaidil. Päritolu on määratletud skeemi (protokolli), hosti (domeeni) ja pordi järgi. Kahel URL-il on sama päritolu siis ja ainult siis, kui neil on sama skeem, host ja port.

Näiteks:

• https://www.example.com/app1/index.html ja https://www.example.com/app2/index.html on sama päritoluga.
• https://www.example.com/index.html ja http://www.example.com/index.html on erineva päritoluga (erinev skeem).
• https://www.example.com/index.html ja https://sub.example.com/index.html on erineva päritoluga (erinev host).
• https://www.example.com:8080/index.html ja https://www.example.com:80/index.html on erineva päritoluga (erinev port).

Kuidas CORS töötab

Kui veebileht teeb päritoluülese päringu, saadab brauser esmalt serverile "eelpäringu" (preflight request). Eelpäring kasutab HTTP OPTIONS meetodit ja sisaldab päiseid, mis näitavad HTTP meetodit ja päiseid, mida tegelik päring kasutab. Server vastab seejärel päistega, mis näitavad, kas päritoluülene päring on lubatud.

Kui server lubab päringu, lisab see vastusesse Access-Control-Allow-Origin päise. See päis määrab päritolu(d), millel on lubatud ressursile juurde pääseda. Seejärel jätkab brauser tegeliku päringuga. Kui server ei luba päringut, ei lisa see Access-Control-Allow-Origin päist ja brauser blokeerib päringu.

CORS päised: detailne ülevaade

CORS tugineb HTTP päistele, et suhelda brauseri ja serveri vahel. Siin on peamised CORS päised:

• Access-Control-Allow-Origin: Määrab päritolu(d), millel on lubatud ressursile juurde pääseda. See päis võib sisaldada konkreetset päritolu (nt https://www.example.com), metamärki (*) või väärtust null. * kasutamine lubab päringuid mis tahes päritolust, mis turvalisuse kaalutlustel üldiselt ei ole soovitatav. null kasutamine on asjakohane ainult "läbipaistmatute vastuste" puhul, näiteks kui ressurss hangitakse file:// protokolli või data URI abil.
• Access-Control-Allow-Methods: Määrab HTTP meetodid, mis on päritoluülese päringu jaoks lubatud (nt GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Määrab HTTP päised, mis on päritoluüleses päringus lubatud. See on oluline kohandatud päiste käsitlemiseks.
• Access-Control-Allow-Credentials: Näitab, kas brauser peaks päritoluülesesse päringusse lisama mandaate (nt küpsiseid, autoriseerimispäiseid). See päis peab olema seatud väärtusele true, et lubada mandaate.
• Access-Control-Expose-Headers: Määrab, milliseid päiseid saab kliendile eksponeerida. Vaikimisi eksponeeritakse ainult piiratud hulk päiseid.
• Access-Control-Max-Age: Määrab maksimaalse aja (sekundites), mille jooksul brauser saab eelpäringut vahemällu salvestada.
• Origin: See on päringu päis, mille brauser saadab, et näidata päringu päritolu.
• Vary: Üldine HTTP päis, kuid CORS-i jaoks oluline. Kui Access-Control-Allow-Origin genereeritakse dünaamiliselt, tuleks vastusesse lisada Vary: Origin päis, et anda vahemälumehhanismidele teada, et vastus varieerub sõltuvalt Origin päringu päisest.

Praktilised CORS näited

Vaatame mõningaid praktilisi näiteid CORS konfiguratsioonidest:

Näide 1: Päringute lubamine konkreetsest päritolust

See konfiguratsioon lubab päringuid ainult aadressilt https://www.example.com:

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

              
                Copy
              
            
          

Näide 2: Päringute lubamine mis tahes päritolust (ei ole soovitatav)

See konfiguratsioon lubab päringuid mis tahes päritolust. Kasutage ettevaatusega, kuna see võib tekitada turvariske:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

Näide 3: Spetsiifiliste meetodite ja päiste lubamine

See konfiguratsioon lubab GET, POST ja PUT meetodeid ning Content-Type ja Authorization päiseid:

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

              
                Copy
              
            
          

Näide 4: Mandaatide lubamine

Mandaatide (nt küpsiste) lubamiseks peate seadma Access-Control-Allow-Credentials väärtuseks true ja määrama konkreetse päritolu (mandaatide lubamisel ei saa kasutada *):

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

              
                Copy
              
            
          

Samuti peate oma JavaScripti fetch/XMLHttpRequest päringus seadma credentials: 'include'.

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

              
                Copy
              
            
          

CORS eelpäringud

Teatud tüüpi päritoluüleste päringute puhul (nt päringud kohandatud päiste või muude meetoditega kui GET, HEAD või POST koos Content-Type väärtusega application/x-www-form-urlencoded, multipart/form-data või text/plain), saadab brauser eelpäringu kasutades OPTIONS meetodit. Server peab vastama eelpäringule sobivate CORS päistega, et näidata, kas tegelik päring on lubatud.

Siin on näide eelpäringust ja vastusest:

Eelpäring (OPTIONS):

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

              
                Copy
              
            
          

Eelvastus (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
              
            
          

Access-Control-Max-Age päis määrab, kui kaua brauser saab eelvastust vahemälus hoida, vähendades eelpäringute arvu.

CORS ja JSONP

JSON with Padding (JSONP) on vanem tehnika sama päritolu poliitikast möödahiilimiseks. Kuid JSONP-l on olulisi turvariske ja seda tuleks vältida CORS-i kasuks. JSONP tugineb <script> siltide lehele süstimisele, mis võib käivitada suvalist koodi. CORS pakub turvalisemat ja paindlikumat viisi päritoluüleste päringute käsitlemiseks.

CORS parimad praktikad

• Vältige * kasutamist: Vältige metamärgi (*) kasutamist Access-Control-Allow-Origin päises, kuna see lubab päringuid mis tahes päritolust. Selle asemel määrake konkreetsed päritolud, millel on lubatud ressursile juurde pääseda.
• Olge meetodite ja päistega spetsiifiline: Määratlege täpsed HTTP meetodid ja päised, mis on lubatud Access-Control-Allow-Methods ja Access-Control-Allow-Headers päistes.
• Kasutage Access-Control-Allow-Credentials ettevaatlikult: Lubage Access-Control-Allow-Credentials ainult siis, kui peate lubama mandaate (nt küpsiseid) päritoluülestes päringutes. Olge teadlik mandaatide lubamisega kaasnevatest turvamõjudest.
• Turvake oma eelpäringud: Veenduge, et teie server käsitleb eelpäringuid õigesti ja tagastab õiged CORS päised.
• Kasutage HTTPS-i: Kasutage alati HTTPS-i nii päritolu kui ka ressursside jaoks, millele te päritoluüleselt juurde pääsete. See aitab kaitsta vahendusrünnakute (man-in-the-middle) eest.
• Vary: Origin: Kui genereerite dünaamiliselt Access-Control-Allow-Origin päist, lisage alati Vary: Origin päis, et vältida vahemäluprobleeme.

CSP ja CORS praktikas: kombineeritud lähenemine

Kuigi nii CSP kui ka CORS tegelevad turvaprobleemidega, toimivad nad erinevatel kihtidel ja pakuvad täiendavat kaitset. CSP keskendub brauseri takistamisele pahatahtliku sisu laadimisel, samas kui CORS keskendub sellele, millised päritolud saavad teie serveri ressurssidele juurde pääseda.

Kombineerides CSP-d ja CORS-i, saate luua oma veebirakendustele tugevama turvaasendi. Näiteks saate kasutada CSP-d, et piirata allikaid, kust skripte saab laadida, ja CORS-i, et kontrollida, millised päritolud saavad teie API lõpp-punktidele juurde pääseda.

Näide: API turvamine CSP ja CORS-iga

Oletame, et teil on API, mis asub aadressil https://api.example.com ja soovite, et see oleks kättesaadav ainult aadressilt https://www.example.com. Saate oma serveri konfigureerida tagastama järgmised päised:

API vastuse päised (https://api.example.com):

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

              
                Copy
              
            
          

Ja saate oma veebisaidi (https://www.example.com) konfigureerida kasutama järgmist CSP päist:

Veebisaidi CSP päis (https://www.example.com):

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

              
                Copy
              
            
          

See CSP poliitika lubab veebisaidil laadida skripte ja ühenduda API-ga, kuid takistab sellel skriptide laadimist või teiste domeenidega ühendumist.

Kokkuvõte

Sisuturbe poliitika (CSP) ja päritoluülene ressursijagamine (CORS) on olulised tööriistad teie esirakenduste turvalisuse tugevdamiseks. Hoolikalt konfigureerides CSP-d ja CORS-i saate oluliselt vähendada XSS-rünnakute, andmesisestusrünnakute ja muude turvaaukude riski. Ärge unustage alustada piirava poliitikaga, testida põhjalikult ning pidevalt jälgida ja täiustada oma konfiguratsiooni, et kohaneda muutustega teie rakenduses ja arenevas ohumaastikus. Esirakenduse turvalisuse esikohale seadmisega saate kaitsta oma kasutajaid ja tagada oma veebirakenduste terviklikkuse tänapäeva üha keerulisemas digitaalses maailmas.