Frontend drošības stiprināšana: Satura drošības politika (CSP) un CORS

Mūsdienu savstarpēji saistītajā digitālajā vidē frontend drošība ir vissvarīgākā. Tīmekļa lietojumprogrammas arvien biežāk kļūst par sarežģītu uzbrukumu mērķi, tāpēc stabili drošības pasākumi ir būtiski. Divi kritiski svarīgi drošas frontend arhitektūras komponenti ir Satura drošības politika (Content Security Policy — CSP) un starpizcelsmju resursu koplietošana (Cross-Origin Resource Sharing — CORS). Šis visaptverošais ceļvedis sniedz padziļinātu ieskatu šajās tehnoloģijās, piedāvājot praktiskus piemērus un noderīgas atziņas, kas palīdzēs jums stiprināt savas tīmekļa lietojumprogrammas pret mūsdienu apdraudējumiem.

Kas ir Satura drošības politika (CSP)?

Satura drošības politika (CSP) ir papildu drošības slānis, kas palīdz atklāt un mazināt noteikta veida uzbrukumus, tostarp starpvietņu skriptošanas (Cross-Site Scripting — XSS) un datu injekcijas uzbrukumus. CSP tiek ieviesta, tīmekļa serverim nosūtot pārlūkprogrammai Content-Security-Policy HTTP atbildes galveni. Šī galvene definē avotu "balto sarakstu", no kuriem pārlūkprogrammai ir atļauts ielādēt resursus. Ierobežojot satura avotus, no kuriem pārlūkprogramma var ielādēt, CSP ievērojami apgrūtina uzbrucējiem ļaunprātīga koda ievadīšanu jūsu vietnē.

Kā darbojas CSP

CSP darbojas, norādot pārlūkprogrammai ielādēt resursus (piemēram, skriptus, stila lapas, attēlus, fontus) tikai no apstiprinātiem avotiem. Šie avoti ir norādīti CSP galvenē, izmantojot direktīvas. Ja pārlūkprogramma mēģina ielādēt resursu no avota, kas nav skaidri atļauts, tā bloķēs pieprasījumu un ziņos par pārkāpumu.

CSP direktīvas: visaptverošs pārskats

CSP direktīvas kontrolē resursu veidus, kurus var ielādēt no konkrētiem avotiem. Šeit ir dažu svarīgāko direktīvu sadalījums:

• default-src: Norāda noklusējuma avotu visiem satura veidiem. Šī ir rezerves direktīva, kas tiek piemērota, ja nav citu, specifiskāku direktīvu.
• script-src: Norāda avotus, no kuriem var ielādēt skriptus. Tas ir ļoti svarīgi, lai novērstu XSS uzbrukumus.
• style-src: Norāda avotus, no kuriem var ielādēt stila lapas.
• img-src: Norāda avotus, no kuriem var ielādēt attēlus.
• font-src: Norāda avotus, no kuriem var ielādēt fontus.
• media-src: Norāda avotus, no kuriem var ielādēt audio un video.
• object-src: Norāda avotus, no kuriem var ielādēt spraudņus (piem., Flash). Bieži vien tiek iestatīts uz 'none', lai pilnībā atspējotu spraudņus to raksturīgo drošības risku dēļ.
• frame-src: Norāda avotus, no kuriem var ielādēt ietvarus (piem., <iframe>).
• connect-src: Norāda URL, ar kuriem lietotāja aģents var izveidot savienojumu, izmantojot skriptu saskarnes, piemēram, XMLHttpRequest, WebSocket un EventSource.
• base-uri: Norāda URL, kurus var izmantot dokumenta <base> elementā.
• form-action: Norāda URL, uz kuriem var nosūtīt veidlapu datus.
• upgrade-insecure-requests: Norāda lietotāja aģentam automātiski pārvērst nedrošus pieprasījumus (HTTP) par drošiem pieprasījumiem (HTTPS).
• report-uri: Norāda URL, uz kuru pārlūkprogrammai jānosūta ziņojumi par CSP pārkāpumiem. Šī direktīva ir novecojusi un aizstāta ar `report-to`.
• report-to: Norāda `Report-To` galvenē definētu ziņošanas grupas nosaukumu, uz kuru pārlūkprogrammai jānosūta ziņojumi par CSP pārkāpumiem.

CSP avotu saraksta atslēgvārdi

CSP direktīvās varat izmantot avotu saraksta atslēgvārdus, lai definētu atļautos avotus. Šeit ir daži izplatīti atslēgvārdi:

• 'self': Atļauj resursus no tās pašas izcelsmes (shēma un resursdators) kā dokuments.
• 'none': Aizliedz resursus no visiem avotiem.
• 'unsafe-inline': Atļauj izmantot iekļautos skriptus un stilus (piemēram, <script> tagus un stila atribūtus). Lietot ar īpašu piesardzību, jo tas ievērojami vājina CSP aizsardzību pret XSS.
• 'unsafe-eval': Atļauj izmantot dinamiskā koda izvērtēšanas funkcijas, piemēram, eval() un Function(). Lietot ar īpašu piesardzību, jo tas rada ievērojamus drošības riskus.
• 'unsafe-hashes': Atļauj konkrētus iekļautos notikumu apstrādātājus vai <style> tagus, kas atbilst norādītajam jaucējkodam (hash). Nepieciešams pārlūkprogrammas atbalsts. Lietot piesardzīgi.
• 'strict-dynamic': Norāda, ka uzticība, kas skaidri piešķirta iezīmē esošam skriptam, pievienojot tam vienreizlietojamu kodu (nonce) vai jaucējkodu, tiek pārnesta uz visiem skriptiem, ko ielādē šis saknes skripts.
• data: Atļauj data: URI (piemēram, iekļautus attēlus, kas kodēti kā base64). Lietot piesardzīgi.
• https:: Atļauj resursu ielādi, izmantojot HTTPS no jebkura domēna.
• [hostname]: Atļauj resursus no konkrēta domēna (piem., example.com). Varat arī norādīt porta numuru (piem., example.com:8080).
• [scheme]://[hostname]:[port]: Pilnībā kvalificēts URI, kas atļauj resursus no norādītās shēmas, resursdatora un porta.

Praktiski CSP piemēri

Apskatīsim dažus praktiskus CSP galveņu piemērus:

1. piemērs: pamata CSP ar 'self'

Šī politika atļauj resursus tikai no tās pašas izcelsmes:

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

              
                Copy
              
            
          

2. piemērs: skriptu atļaušana no konkrēta domēna

Šī politika atļauj skriptus no jūsu pašu domēna un uzticama CDN:

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

              
                Copy
              
            
          

3. piemērs: iekļauto skriptu un stilu atspējošana

Šī politika aizliedz iekļautos skriptus un stilus, kas ir spēcīga aizsardzība pret XSS:

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

              
                Copy
              
            
          

Svarīgi: Lai atspējotu iekļautos skriptus, ir nepieciešams pārveidot HTML, pārvietojot iekļautos skriptus uz ārējiem failiem.

4. piemērs: vienreizlietojamu kodu (nonces) izmantošana iekļautajiem skriptiem

Ja jums tomēr jāizmanto iekļautie skripti, izmantojiet vienreizlietojamus kodus (kriptogrāfiski nejaušus, vienreiz lietojamus marķierus), lai iekļautu baltajā sarakstā konkrētus iekļauto skriptu blokus. Tas ir drošāk nekā 'unsafe-inline'. Serverim ir jāģenerē unikāls vienreizlietojams kods katram pieprasījumam un jāiekļauj tas gan CSP galvenē, gan <script> tagā.

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

              
                Copy
              
            
          

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

              
                Copy
              
            
          

Piezīme: Atcerieties ģenerēt jaunu vienreizlietojamu kodu katram pieprasījumam. Neizmantojiet vienreizlietojamus kodus atkārtoti!

5. piemērs: jaucējkodu (hashes) izmantošana iekļautajiem stiliem

Līdzīgi kā vienreizlietojamus kodus, jaucējkodus var izmantot, lai iekļautu baltajā sarakstā konkrētus iekļautos <style> blokus. To dara, ģenerējot SHA256, SHA384 vai SHA512 jaucējkodu no stila satura.

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

              
                Copy
              
            
          

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

              
                Copy
              
            
          

Piezīme: Jaucējkodi ir mazāk elastīgi nekā vienreizlietojamie kodi, jo jebkuras izmaiņas stila saturā padarīs jaucējkodu nederīgu.

6. piemērs: ziņošana par CSP pārkāpumiem

Lai pārraudzītu CSP pārkāpumus, izmantojiet report-uri vai report-to direktīvu:

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

              
                Copy
              
            
          

Jums būs arī jākonfigurē Report-To galvene. Report-To galvene definē vienu vai vairākas ziņošanas grupas, kas norāda, kur un kā ziņojumi jānosūta.

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

              
                Copy
              
            
          

CSP testēšana un ieviešana

CSP ieviešana prasa rūpīgu plānošanu un testēšanu. Sāciet ar ierobežojošu politiku un pakāpeniski to mīkstiniet pēc nepieciešamības. Izmantojiet Content-Security-Policy-Report-Only galveni, lai testētu savu politiku, nebloķējot resursus. Šī galvene ziņo par pārkāpumiem, nepiespiežot politiku, ļaujot jums identificēt un novērst problēmas pirms politikas ieviešanas produkcijā.

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

              
                Copy
              
            
          

Analizējiet pārlūkprogrammas ģenerētos ziņojumus, lai identificētu jebkādus pārkāpumus un attiecīgi pielāgotu savu politiku. Kad esat pārliecināts, ka jūsu politika darbojas pareizi, ieviesiet to, izmantojot Content-Security-Policy galveni.

Labākās prakses CSP

• Sāciet ar default-src: Vienmēr definējiet default-src, lai izveidotu pamata politiku.
• Esiet specifiski: Izmantojiet specifiskas direktīvas un avotu saraksta atslēgvārdus, lai ierobežotu savas politikas tvērumu.
• Izvairieties no 'unsafe-inline' un 'unsafe-eval': Šie atslēgvārdi ievērojami vājina CSP, un no tiem vajadzētu izvairīties, kad vien iespējams.
• Izmantojiet vienreizlietojamus kodus vai jaucējkodus iekļautajiem skriptiem un stiliem: Ja jums tomēr jāizmanto iekļautie skripti vai stili, izmantojiet vienreizlietojamus kodus vai jaucējkodus, lai iekļautu baltajā sarakstā konkrētus koda blokus.
• Pārraugiet CSP pārkāpumus: Izmantojiet report-uri vai report-to direktīvu, lai pārraudzītu CSP pārkāpumus un attiecīgi pielāgotu savu politiku.
• Rūpīgi testējiet: Izmantojiet Content-Security-Policy-Report-Only galveni, lai testētu savu politiku pirms tās ieviešanas produkcijā.
• Atkārtojiet un pilnveidojiet: CSP nav vienreizēja konfigurācija. Nepārtraukti pārraugiet un pilnveidojiet savu politiku, lai pielāgotos izmaiņām jūsu lietojumprogrammā un apdraudējumu vidē.

Kas ir starpizcelsmju resursu koplietošana (CORS)?

Starpizcelsmju resursu koplietošana (CORS) ir mehānisms, kas ļauj tīmekļa lapām no vienas izcelsmes (domēna) piekļūt resursiem no citas izcelsmes. Pēc noklusējuma pārlūkprogrammas piemēro vienādas izcelsmes politiku (Same-Origin Policy), kas neļauj skriptiem veikt pieprasījumus uz citu izcelsmi, nekā tā, no kuras skripts nācis. CORS nodrošina veidu, kā selektīvi mīkstināt šo ierobežojumu, atļaujot leģitīmus starpizcelsmju pieprasījumus, vienlaikus aizsargājot pret ļaunprātīgiem uzbrukumiem.

Izpratne par vienādas izcelsmes politiku

Vienādas izcelsmes politika ir fundamentāls drošības mehānisms, kas neļauj ļaunprātīgam skriptam no vienas vietnes piekļūt sensitīviem datiem citā vietnē. Izcelsmi definē shēma (protokols), resursdators (domēns) un ports. Diviem URL ir viena un tā pati izcelsme tikai tad, ja tiem ir viena un tā pati shēma, resursdators un ports.

Piemēram:

• https://www.example.com/app1/index.html un https://www.example.com/app2/index.html ir viena izcelsme.
• https://www.example.com/index.html un http://www.example.com/index.html ir dažādas izcelsmes (atšķirīga shēma).
• https://www.example.com/index.html un https://sub.example.com/index.html ir dažādas izcelsmes (atšķirīgs resursdators).
• https://www.example.com:8080/index.html un https://www.example.com:80/index.html ir dažādas izcelsmes (atšķirīgs ports).

Kā darbojas CORS

Kad tīmekļa lapa veic starpizcelsmju pieprasījumu, pārlūkprogramma vispirms nosūta serverim "sākotnējās pārbaudes" (preflight) pieprasījumu. Sākotnējās pārbaudes pieprasījums izmanto HTTP OPTIONS metodi un ietver galvenes, kas norāda HTTP metodi un galvenes, kuras izmantos faktiskais pieprasījums. Pēc tam serveris atbild ar galvenēm, kas norāda, vai starpizcelsmju pieprasījums ir atļauts.

Ja serveris atļauj pieprasījumu, tas atbildē iekļauj Access-Control-Allow-Origin galveni. Šī galvene norāda izcelsmi(-es), kurām ir atļauts piekļūt resursam. Pēc tam pārlūkprogramma turpina ar faktisko pieprasījumu. Ja serveris neatļauj pieprasījumu, tas neiekļauj Access-Control-Allow-Origin galveni, un pārlūkprogramma bloķē pieprasījumu.

CORS galvenes: detalizēts apskats

CORS paļaujas uz HTTP galvenēm, lai sazinātos starp pārlūkprogrammu un serveri. Šeit ir galvenās CORS galvenes:

• Access-Control-Allow-Origin: Norāda izcelsmi(-es), kurām ir atļauts piekļūt resursam. Šī galvene var saturēt konkrētu izcelsmi (piemēram, https://www.example.com), aizstājējzīmi (*) vai null. Izmantojot *, tiek atļauti pieprasījumi no jebkuras izcelsmes, kas drošības apsvērumu dēļ parasti nav ieteicams. Izmantot `null` ir piemēroti tikai "necaurspīdīgām atbildēm", piemēram, kad resurss tiek iegūts, izmantojot `file://` protokolu vai data URI.
• Access-Control-Allow-Methods: Norāda HTTP metodes, kas ir atļautas starpizcelsmju pieprasījumam (piemēram, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Norāda HTTP galvenes, kas ir atļautas starpizcelsmju pieprasījumā. Tas ir svarīgi, lai apstrādātu pielāgotas galvenes.
• Access-Control-Allow-Credentials: Norāda, vai pārlūkprogrammai jāiekļauj akreditācijas dati (piemēram, sīkfaili, autorizācijas galvenes) starpizcelsmju pieprasījumā. Šai galvenei jābūt iestatītai uz true, lai atļautu akreditācijas datus.
• Access-Control-Expose-Headers: Norāda, kuras galvenes var tikt atklātas klientam. Pēc noklusējuma tiek atklāts tikai ierobežots galveņu kopums.
• Access-Control-Max-Age: Norāda maksimālo laiku (sekundēs), cik ilgi pārlūkprogramma var kešot sākotnējās pārbaudes pieprasījumu.
• Origin: Šī ir pieprasījuma galvene, ko nosūta pārlūkprogramma, lai norādītu pieprasījuma izcelsmi.
• Vary: Vispārīga HTTP galvene, bet svarīga CORS. Kad Access-Control-Allow-Origin tiek dinamiski ģenerēta, atbildē jāiekļauj Vary: Origin galvene, lai norādītu kešošanas mehānismiem, ka atbilde mainās atkarībā no Origin pieprasījuma galvenes.

Praktiski CORS piemēri

Apskatīsim dažus praktiskus CORS konfigurāciju piemērus:

1. piemērs: pieprasījumu atļaušana no konkrētas izcelsmes

Šī konfigurācija atļauj pieprasījumus tikai no https://www.example.com:

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

              
                Copy
              
            
          

2. piemērs: pieprasījumu atļaušana no jebkuras izcelsmes (nav ieteicams)

Šī konfigurācija atļauj pieprasījumus no jebkuras izcelsmes. Lietot piesardzīgi, jo tas var radīt drošības riskus:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

3. piemērs: konkrētu metožu un galveņu atļaušana

Šī konfigurācija atļauj GET, POST un PUT metodes, kā arī Content-Type un Authorization galvenes:

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

              
                Copy
              
            
          

4. piemērs: akreditācijas datu atļaušana

Lai atļautu akreditācijas datus (piemēram, sīkfailus), jums jāiestata Access-Control-Allow-Credentials uz true un jānorāda konkrēta izcelsme (jūs nevarat izmantot *, atļaujot akreditācijas datus):

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

              
                Copy
              
            
          

Jums arī jāiestata credentials: 'include' savā JavaScript fetch/XMLHttpRequest pieprasījumā.

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

              
                Copy
              
            
          

CORS sākotnējās pārbaudes pieprasījumi

Noteikta veida starpizcelsmju pieprasījumiem (piemēram, pieprasījumiem ar pielāgotām galvenēm vai metodēm, kas nav GET, HEAD vai POST ar Content-Type application/x-www-form-urlencoded, multipart/form-data vai text/plain), pārlūkprogramma nosūta sākotnējās pārbaudes pieprasījumu, izmantojot OPTIONS metodi. Serverim ir jāatbild uz sākotnējās pārbaudes pieprasījumu ar atbilstošām CORS galvenēm, lai norādītu, vai faktiskais pieprasījums ir atļauts.

Šeit ir sākotnējās pārbaudes pieprasījuma un atbildes piemērs:

Sākotnējās pārbaudes pieprasījums (OPTIONS):

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

              
                Copy
              
            
          

Sākotnējās pārbaudes atbilde (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 galvene norāda, cik ilgi pārlūkprogramma var kešot sākotnējās pārbaudes atbildi, samazinot sākotnējās pārbaudes pieprasījumu skaitu.

CORS un JSONP

JSON ar papildinājumu (JSONP) ir vecāka tehnika, lai apietu vienādas izcelsmes politiku. Tomēr JSONP ir saistīts ar ievērojamiem drošības riskiem, un no tā vajadzētu izvairīties, dodot priekšroku CORS. JSONP paļaujas uz <script> tagu ievietošanu lapā, kas var izpildīt jebkādu kodu. CORS nodrošina drošāku un elastīgāku veidu, kā apstrādāt starpizcelsmju pieprasījumus.

Labākās prakses CORS

• Izvairieties no *: Izvairieties no aizstājējzīmes (*) izmantošanas Access-Control-Allow-Origin galvenē, jo tā atļauj pieprasījumus no jebkuras izcelsmes. Tā vietā norādiet konkrētu izcelsmi(-es), kurām ir atļauts piekļūt resursam.
• Esiet specifiski ar metodēm un galvenēm: Norādiet precīzas HTTP metodes un galvenes, kas ir atļautas Access-Control-Allow-Methods un Access-Control-Allow-Headers galvenēs.
• Izmantojiet Access-Control-Allow-Credentials piesardzīgi: Iespējojiet Access-Control-Allow-Credentials tikai tad, ja nepieciešams atļaut akreditācijas datus (piemēram, sīkfailus) starpizcelsmju pieprasījumos. Apzinieties drošības sekas, ko rada akreditācijas datu atļaušana.
• Nodrošiniet savus sākotnējās pārbaudes pieprasījumus: Pārliecinieties, ka jūsu serveris pareizi apstrādā sākotnējās pārbaudes pieprasījumus un atgriež pareizās CORS galvenes.
• Izmantojiet HTTPS: Vienmēr izmantojiet HTTPS gan izcelsmei, gan resursiem, kuriem piekļūstat no citas izcelsmes. Tas palīdz aizsargāties pret "man-in-the-middle" uzbrukumiem.
• Vary: Origin: Ja jūs dinamiski ģenerējat Access-Control-Allow-Origin galveni, vienmēr iekļaujiet Vary: Origin galveni, lai novērstu kešošanas problēmas.

CSP un CORS praksē: apvienota pieeja

Lai gan gan CSP, gan CORS risina drošības problēmas, tās darbojas dažādos slāņos un nodrošina papildinošu aizsardzību. CSP koncentrējas uz to, lai neļautu pārlūkprogrammai ielādēt ļaunprātīgu saturu, savukārt CORS koncentrējas uz to, lai kontrolētu, kuras izcelsmes var piekļūt resursiem jūsu serverī.

Apvienojot CSP un CORS, jūs varat izveidot stabilāku drošības stāvokli savām tīmekļa lietojumprogrammām. Piemēram, jūs varat izmantot CSP, lai ierobežotu avotus, no kuriem var ielādēt skriptus, un CORS, lai kontrolētu, kuras izcelsmes var piekļūt jūsu API galapunktiem.

Piemērs: API nodrošināšana ar CSP un CORS

Pieņemsim, ka jums ir API, kas mitināta https://api.example.com, un jūs vēlaties, lai tai varētu piekļūt tikai no https://www.example.com. Jūs varat konfigurēt savu serveri, lai tas atgrieztu šādas galvenes:

API atbildes galvenes (https://api.example.com):

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

              
                Copy
              
            
          

Un jūs varat konfigurēt savu vietni (https://www.example.com), lai tā izmantotu šādu CSP galveni:

Vietnes CSP galvene (https://www.example.com):

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

              
                Copy
              
            
          

Šī CSP politika ļauj vietnei ielādēt skriptus un izveidot savienojumu ar API, bet neļauj tai ielādēt skriptus vai izveidot savienojumu ar citiem domēniem.

Noslēgums

Satura drošības politika (CSP) un starpizcelsmju resursu koplietošana (CORS) ir būtiski rīki jūsu frontend lietojumprogrammu drošības stiprināšanai. Rūpīgi konfigurējot CSP un CORS, jūs varat ievērojami samazināt XSS uzbrukumu, datu injekcijas uzbrukumu un citu drošības ievainojamību risku. Atcerieties sākt ar ierobežojošu politiku, rūpīgi testēt un nepārtraukti pārraudzīt un pilnveidot savu konfigurāciju, lai pielāgotos izmaiņām jūsu lietojumprogrammā un mainīgajā apdraudējumu vidē. Piešķirot prioritāti frontend drošībai, jūs varat aizsargāt savus lietotājus un nodrošināt savu tīmekļa lietojumprogrammu integritāti mūsdienu arvien sarežģītākajā digitālajā pasaulē.