Front-endin tietoturvan vahvistaminen: Sisällön turvallisuuspolitiikka (CSP) ja CORS

Nykypäivän verkottuneessa digitaalisessa maailmassa front-endin tietoturva on ensisijaisen tärkeää. Verkkosovellukset ovat yhä useammin kehittyneiden hyökkäysten kohteena, mikä tekee vankat turvatoimet välttämättömiksi. Kaksi kriittistä osaa turvallisessa front-end-arkkitehtuurissa ovat sisällön turvallisuuspolitiikka (Content Security Policy, CSP) ja Cross-Origin Resource Sharing (CORS). Tämä kattava opas tarjoaa syvällisen katsauksen näihin teknologioihin, käytännön esimerkkejä ja toimivia oivalluksia, jotka auttavat sinua vahvistamaan verkkosovelluksiasi nykyaikaisia uhkia vastaan.

Mitä on sisällön turvallisuuspolitiikka (CSP)?

Sisällön turvallisuuspolitiikka (CSP) on lisäsuojakerros, joka auttaa havaitsemaan ja lieventämään tietyntyyppisiä hyökkäyksiä, kuten sivustojen välistä komentosarjaa (Cross-Site Scripting, XSS) ja datan syöttöhyökkäyksiä. CSP toteutetaan siten, että verkkopalvelin lähettää selaimelle Content-Security-Policy HTTP-vastausotsikon. Tämä otsikko määrittelee sallittujen lähteiden luettelon (whitelist), joista selain saa ladata resursseja. Rajoittamalla lähteitä, joista selain voi ladata sisältöä, CSP tekee hyökkääjien haitallisen koodin syöttämisestä verkkosivustollesi huomattavasti vaikeampaa.

Miten CSP toimii

CSP toimii ohjeistamalla selainta lataamaan resursseja (esim. skriptejä, tyylisivuja, kuvia, fontteja) vain hyväksytyistä lähteistä. Nämä lähteet määritellään CSP-otsikossa direktiivien avulla. Jos selain yrittää ladata resurssin lähteestä, jota ei ole erikseen sallittu, se estää pyynnön ja raportoi rikkomuksesta.

CSP-direktiivit: Kattava yleiskatsaus

CSP-direktiivit hallitsevat, minkä tyyppisiä resursseja tietyistä lähteistä voidaan ladata. Tässä on erittely joistakin tärkeimmistä direktiiveistä:

• default-src: Määrittää oletuslähteen kaikille sisältötyypeille. Tämä on varadirektiivi, jota sovelletaan, kun muita, tarkempia direktiivejä ei ole määritetty.
• script-src: Määrittää lähteet, joista skriptejä voidaan ladata. Tämä on ratkaisevan tärkeää XSS-hyökkäysten estämisessä.
• style-src: Määrittää lähteet, joista tyylisivuja voidaan ladata.
• img-src: Määrittää lähteet, joista kuvia voidaan ladata.
• font-src: Määrittää lähteet, joista fontteja voidaan ladata.
• media-src: Määrittää lähteet, joista ääntä ja videota voidaan ladata.
• object-src: Määrittää lähteet, joista liitännäisiä (esim. Flash) voidaan ladata. Tämä asetetaan usein arvoon 'none' liitännäisten poistamiseksi kokonaan käytöstä niiden luontaisten turvallisuusriskien vuoksi.
• frame-src: Määrittää lähteet, joista kehyksiä (esim. <iframe>) voidaan ladata.
• connect-src: Määrittää URL-osoitteet, joihin käyttäjäagentti voi yhdistää skriptirajapintojen, kuten XMLHttpRequest, WebSocket ja EventSource, avulla.
• base-uri: Määrittää URL-osoitteet, joita voidaan käyttää dokumentin <base>-elementissä.
• form-action: Määrittää URL-osoitteet, joihin lomakkeiden lähetykset voidaan lähettää.
• upgrade-insecure-requests: Ohjeistaa käyttäjäagenttia päivittämään automaattisesti turvattomat pyynnöt (HTTP) turvallisiksi pyynnöiksi (HTTPS).
• report-uri: Määrittää URL-osoitteen, jonne selaimen tulisi lähettää raportteja CSP-rikkomuksista. Tämä direktiivi on vanhentunut ja korvattu `report-to`-direktiivillä.
• report-to: Määrittää `Report-To`-otsikossa määritellyn raportointiryhmän nimen, jonne selaimen tulisi lähettää raportteja CSP-rikkomuksista.

CSP-lähdeluettelon avainsanat

CSP-direktiivien sisällä voit käyttää lähdeluettelon avainsanoja sallittujen lähteiden määrittämiseen. Tässä on joitakin yleisiä avainsanoja:

• 'self': Sallii resurssit samasta alkuperästä (protokolla ja isäntä) kuin dokumentti.
• 'none': Kieltää resurssit kaikista lähteistä.
• 'unsafe-inline': Sallii sisäisten skriptien ja tyylien käytön (esim. <script>-tagit ja style-attribuutit). Käytä erittäin varoen, koska se heikentää merkittävästi CSP-suojausta XSS-hyökkäyksiä vastaan.
• 'unsafe-eval': Sallii dynaamisen koodin suoritusfunktioiden, kuten eval() ja Function(), käytön. Käytä erittäin varoen, koska se aiheuttaa merkittäviä turvallisuusriskejä.
• 'unsafe-hashes': Sallii tietyt sisäiset tapahtumankäsittelijät tai <style>-tagit, jotka vastaavat määritettyä hajautusarvoa. Vaatii selainta. Käytä varoen.
• 'strict-dynamic': Määrittää, että merkintäkielessä olevalle skriptille nimenomaisesti annettu luottamus (nonce-arvon tai hajautusarvon avulla) välitetään kaikille kyseisen juuriskriptin lataamille skripteille.
• data: Sallii data:-URI-osoitteet (esim. base64-koodatut sisäiset kuvat). Käytä varoen.
• https:: Sallii resurssien lataamisen HTTPS-protokollan kautta mistä tahansa verkkotunnuksesta.
• [hostname]: Sallii resurssit tietyltä verkkotunnukselta (esim. example.com). Voit myös määrittää porttinumeron (esim. example.com:8080).
• [scheme]://[hostname]:[port]: Täysin määritelty URI, joka sallii resurssit määritetystä protokollasta, isännästä ja portista.

Käytännön CSP-esimerkkejä

Katsotaanpa muutamia käytännön esimerkkejä CSP-otsikoista:

Esimerkki 1: Perus-CSP 'self'-arvolla

Tämä politiikka sallii resurssit vain samasta alkuperästä:

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

              
                Copy
              
            
          

Esimerkki 2: Skriptien salliminen tietyltä verkkotunnukselta

Tämä politiikka sallii skriptit omalta verkkotunnukseltasi ja luotetulta CDN-palvelimelta:

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

              
                Copy
              
            
          

Esimerkki 3: Sisäisten skriptien ja tyylien kieltäminen

Tämä politiikka kieltää sisäiset skriptit ja tyylit, mikä on vahva puolustus XSS-hyökkäyksiä vastaan:

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

              
                Copy
              
            
          

Tärkeää: Sisäisten skriptien poistaminen käytöstä vaatii HTML-koodin uudelleenjärjestelyä, jotta sisäiset skriptit siirretään ulkoisiin tiedostoihin.

Esimerkki 4: Nonce-arvojen käyttö sisäisille skripteille

Jos sinun on käytettävä sisäisiä skriptejä, käytä nonce-arvoja (kryptografisesti satunnaisia, kertakäyttöisiä tunnisteita) salliaksesi tietyt sisäiset skriptilohkot. Tämä on turvallisempaa kuin 'unsafe-inline'. Palvelimen on luotava yksilöllinen nonce-arvo jokaista pyyntöä varten ja sisällytettävä se sekä CSP-otsikkoon että <script>-tagiin.

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

              
                Copy
              
            
          

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

              
                Copy
              
            
          

Huomautus: Muista luoda uusi nonce-arvo jokaista pyyntöä varten. Älä käytä nonce-arvoja uudelleen!

Esimerkki 5: Hajautusarvojen käyttö sisäisille tyyleille

Nonce-arvojen tapaan hajautusarvoja voidaan käyttää tiettyjen sisäisten <style>-lohkojen sallimiseen. Tämä tehdään luomalla SHA256-, SHA384- tai SHA512-hajautusarvo tyylin sisällöstä.

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

              
                Copy
              
            
          

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

              
                Copy
              
            
          

Huomautus: Hajautusarvot ovat vähemmän joustavia kuin nonce-arvot, koska mikä tahansa muutos tyylin sisältöön mitätöi hajautusarvon.

Esimerkki 6: CSP-rikkomusten raportointi

Valvoaksesi CSP-rikkomuksia, käytä report-uri- tai report-to-direktiiviä:

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

              
                Copy
              
            
          

Sinun on myös määritettävä Report-To-otsikko. Report-To-otsikko määrittelee yhden tai useamman raportointiryhmän, jotka määrittävät, minne ja miten raportit tulisi lähettää.

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

              
                Copy
              
            
          

CSP:n testaus ja käyttöönotto

CSP:n käyttöönotto vaatii huolellista suunnittelua ja testausta. Aloita rajoittavalla politiikalla ja löysää sitä vähitellen tarpeen mukaan. Käytä Content-Security-Policy-Report-Only-otsikkoa testataksesi politiikkaasi estämättä resursseja. Tämä otsikko raportoi rikkomuksista mutta ei pakota politiikkaa voimaan, mikä antaa sinun tunnistaa ja korjata ongelmat ennen politiikan käyttöönottoa tuotannossa.

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

              
                Copy
              
            
          

Analysoi selaimen luomia raportteja tunnistaaksesi mahdolliset rikkomukset ja säädä politiikkaasi vastaavasti. Kun olet varma, että politiikkasi toimii oikein, ota se käyttöön käyttämällä Content-Security-Policy-otsikkoa.

CSP:n parhaat käytännöt

• Aloita default-src:llä: Määritä aina default-src luodaksesi peruspolitiikan.
• Ole tarkka: Käytä tiettyjä direktiivejä ja lähdeluettelon avainsanoja rajoittaaksesi politiikkasi laajuutta.
• Vältä 'unsafe-inline' ja 'unsafe-eval': Nämä avainsanat heikentävät merkittävästi CSP:tä, ja niitä tulisi välttää aina kun mahdollista.
• Käytä nonce- tai hajautusarvoja sisäisille skripteille ja tyyleille: Jos sinun on käytettävä sisäisiä skriptejä tai tyylejä, käytä nonce- tai hajautusarvoja salliaksesi tietyt koodilohkot.
• Valvo CSP-rikkomuksia: Käytä report-uri- tai report-to-direktiiviä valvoaksesi CSP-rikkomuksia ja säädä politiikkaasi vastaavasti.
• Testaa perusteellisesti: Käytä Content-Security-Policy-Report-Only-otsikkoa testataksesi politiikkaasi ennen sen käyttöönottoa tuotannossa.
• Iteroi ja hienosäädä: CSP ei ole kertaluonteinen asetus. Valvo ja hienosäädä politiikkaasi jatkuvasti sopeutuaksesi sovelluksesi muutoksiin ja uhkaympäristöön.

Mitä on Cross-Origin Resource Sharing (CORS)?

Cross-Origin Resource Sharing (CORS) on mekanismi, joka antaa verkkosivuille luvan käyttää resursseja toisesta alkuperästä (domainista). Oletusarvoisesti selaimet noudattavat saman alkuperän käytäntöä (Same-Origin Policy), joka estää skriptejä tekemästä pyyntöjä eri alkuperään kuin mistä skripti itse on peräisin. CORS tarjoaa tavan höllentää tätä rajoitusta valikoivasti, sallien lailliset alkuperien väliset pyynnöt samalla suojaten haitallisilta hyökkäyksiltä.

Saman alkuperän käytännön ymmärtäminen

Saman alkuperän käytäntö on perustavanlaatuinen turvallisuusmekanismi, joka estää haitallista skriptiä yhdeltä verkkosivustolta pääsemästä käsiksi arkaluontoisiin tietoihin toisella verkkosivustolla. Alkuperä määritellään protokollan (scheme), isännän (host) ja portin perusteella. Kahdella URL-osoitteella on sama alkuperä, jos ja vain jos niillä on sama protokolla, isäntä ja portti.

Esimerkiksi:

• https://www.example.com/app1/index.html ja https://www.example.com/app2/index.html ovat samasta alkuperästä.
• https://www.example.com/index.html ja http://www.example.com/index.html ovat eri alkuperistä (eri protokolla).
• https://www.example.com/index.html ja https://sub.example.com/index.html ovat eri alkuperistä (eri isäntä).
• https://www.example.com:8080/index.html ja https://www.example.com:80/index.html ovat eri alkuperistä (eri portti).

Miten CORS toimii

Kun verkkosivu tekee alkuperien välisen pyynnön, selain lähettää ensin palvelimelle "esikyselypyynnön" (preflight request). Esikyselypyyntö käyttää HTTP OPTIONS -metodia ja sisältää otsikoita, jotka kertovat, mitä HTTP-metodia ja otsikoita varsinainen pyyntö tulee käyttämään. Palvelin vastaa sitten otsikoilla, jotka ilmaisevat, onko alkuperien välinen pyyntö sallittu.

Jos palvelin sallii pyynnön, se sisällyttää vastaukseen Access-Control-Allow-Origin-otsikon. Tämä otsikko määrittää alkuperän (tai alkuperät), joilla on lupa käyttää resurssia. Selain jatkaa sitten varsinaisella pyynnöllä. Jos palvelin ei salli pyyntöä, se ei sisällytä Access-Control-Allow-Origin-otsikkoa, ja selain estää pyynnön.

CORS-otsikot: Yksityiskohtainen tarkastelu

CORS perustuu HTTP-otsikoihin kommunikoidakseen selaimen ja palvelimen välillä. Tässä ovat keskeisimmät CORS-otsikot:

• Access-Control-Allow-Origin: Määrittää alkuperän (tai alkuperät), joilla on lupa käyttää resurssia. Tämä otsikko voi sisältää tietyn alkuperän (esim. https://www.example.com), jokerimerkin (*) tai null. *-merkin käyttö sallii pyynnöt mistä tahansa alkuperästä, mitä ei yleensä suositella turvallisuussyistä. `null`-arvon käyttö on sopivaa vain "läpinäkymättömille vastauksille", kuten kun resurssi haetaan `file://`-protokollalla tai data-URI:lla.
• Access-Control-Allow-Methods: Määrittää HTTP-metodit, jotka ovat sallittuja alkuperien välisessä pyynnössä (esim. GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Määrittää HTTP-otsikot, jotka ovat sallittuja alkuperien välisessä pyynnössä. Tämä on tärkeää mukautettujen otsikoiden käsittelyssä.
• Access-Control-Allow-Credentials: Ilmaisee, tuleeko selaimen sisällyttää tunnistetietoja (esim. evästeitä, valtuutusotsikoita) alkuperien väliseen pyyntöön. Tämä otsikko on asetettava arvoon true tunnistetietojen sallimiseksi.
• Access-Control-Expose-Headers: Määrittää, mitkä otsikot voidaan paljastaa asiakkaalle. Oletusarvoisesti vain rajallinen joukko otsikoita on paljastettu.
• Access-Control-Max-Age: Määrittää enimmäisajan (sekunneissa), jonka selain voi tallentaa esikyselypyynnön välimuistiin.
• Origin: Tämä on selaimen lähettämä pyyntöotsikko, joka ilmaisee pyynnön alkuperän.
• Vary: Yleinen HTTP-otsikko, mutta tärkeä CORSin kannalta. Kun `Access-Control-Allow-Origin` luodaan dynaamisesti, `Vary: Origin` -otsikko tulisi sisällyttää vastaukseen ohjeistamaan välimuistimekanismeja, että vastaus vaihtelee `Origin`-pyyntöotsikon perusteella.

Käytännön CORS-esimerkkejä

Katsotaanpa muutamia käytännön esimerkkejä CORS-määrityksistä:

Esimerkki 1: Pyyntöjen salliminen tietystä alkuperästä

Tämä määritys sallii pyynnöt vain osoitteesta https://www.example.com:

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

              
                Copy
              
            
          

Esimerkki 2: Pyyntöjen salliminen mistä tahansa alkuperästä (ei suositella)

Tämä määritys sallii pyynnöt mistä tahansa alkuperästä. Käytä varoen, koska se voi aiheuttaa turvallisuusriskejä:

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

Esimerkki 3: Tiettyjen metodien ja otsikoiden salliminen

Tämä määritys sallii GET-, POST- ja PUT-metodit sekä Content-Type- ja Authorization-otsikot:

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

              
                Copy
              
            
          

Esimerkki 4: Tunnistetietojen salliminen

Salliaksesi tunnistetiedot (esim. evästeet), sinun on asetettava Access-Control-Allow-Credentials arvoon true ja määritettävä tietty alkuperä (et voi käyttää *-merkkiä salliessasi tunnistetietoja):

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

              
                Copy
              
            
          

Sinun on myös asetettava credentials: 'include' JavaScript fetch/XMLHttpRequest -pyynnössäsi.

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

              
                Copy
              
            
          

CORSin esikyselypyynnöt

Tietyntyyppisille alkuperien välisille pyynnöille (esim. pyynnöt, joissa on mukautettuja otsikoita tai muita metodeja kuin GET, HEAD tai POST, jonka Content-Type on application/x-www-form-urlencoded, multipart/form-data tai text/plain), selain lähettää esikyselypyynnön käyttämällä OPTIONS-metodia. Palvelimen on vastattava esikyselypyyntöön asianmukaisilla CORS-otsikoilla ilmoittaakseen, onko varsinainen pyyntö sallittu.

Tässä on esimerkki esikyselypyynnöstä ja -vastauksesta:

Esikyselypyyntö (OPTIONS):

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

              
                Copy
              
            
          

Esikyselyvastaus (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-otsikko määrittää, kuinka kauan selain voi tallentaa esikyselyvastauksen välimuistiin, mikä vähentää esikyselypyyntöjen määrää.

CORS ja JSONP

JSON with Padding (JSONP) on vanhempi tekniikka saman alkuperän käytännön kiertämiseen. JSONP:llä on kuitenkin merkittäviä turvallisuusriskejä, ja sitä tulisi välttää CORSin hyväksi. JSONP perustuu <script>-tagien lisäämiseen sivulle, mikä voi suorittaa mielivaltaista koodia. CORS tarjoaa turvallisemman ja joustavamman tavan käsitellä alkuperien välisiä pyyntöjä.

CORSin parhaat käytännöt

• Vältä *-merkin käyttöä: Vältä jokerimerkin (*) käyttöä Access-Control-Allow-Origin-otsikossa, koska se sallii pyynnöt mistä tahansa alkuperästä. Määritä sen sijaan tietyt alkuperät, joilla on lupa käyttää resurssia.
• Ole tarkka metodien ja otsikoiden kanssa: Määritä tarkat HTTP-metodit ja -otsikot, jotka ovat sallittuja Access-Control-Allow-Methods- ja Access-Control-Allow-Headers-otsikoissa.
• Käytä Access-Control-Allow-Credentials-otsikkoa varoen: Ota Access-Control-Allow-Credentials käyttöön vain, jos sinun on sallittava tunnistetiedot (esim. evästeet) alkuperien välisissä pyynnöissä. Ole tietoinen tunnistetietojen sallimisen turvallisuusvaikutuksista.
• Suojaa esikyselypyyntösi: Varmista, että palvelimesi käsittelee esikyselypyynnöt oikein ja palauttaa oikeat CORS-otsikot.
• Käytä HTTPS:ää: Käytä aina HTTPS:ää sekä alkuperälle että resursseille, joita käytät alkuperien välillä. Tämä auttaa suojaamaan väliintulohyökkäyksiltä.
• Vary: Origin: Jos luot `Access-Control-Allow-Origin`-otsikon dynaamisesti, sisällytä aina `Vary: Origin` -otsikko estääksesi välimuistiongelmia.

CSP ja CORS käytännössä: Yhdistetty lähestymistapa

Vaikka sekä CSP että CORS käsittelevät turvallisuushuolia, ne toimivat eri kerroksissa ja tarjoavat toisiaan täydentävää suojaa. CSP keskittyy estämään selainta lataamasta haitallista sisältöä, kun taas CORS keskittyy hallitsemaan, mitkä alkuperät voivat käyttää resursseja palvelimellasi.

Yhdistämällä CSP:n ja CORSin voit luoda vankemman turvallisuusasenteen verkkosovelluksillesi. Voit esimerkiksi käyttää CSP:tä rajoittaaksesi lähteitä, joista skriptejä voidaan ladata, ja CORSia hallitaksesi, mitkä alkuperät voivat käyttää API-päätepisteitäsi.

Esimerkki: API:n suojaaminen CSP:llä ja CORSilla

Oletetaan, että sinulla on API osoitteessa https://api.example.com, jonka haluat olevan käytettävissä vain osoitteesta https://www.example.com. Voit määrittää palvelimesi palauttamaan seuraavat otsikot:

API-vastausotsikot (https://api.example.com):

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

              
                Copy
              
            
          

Ja voit määrittää verkkosivustosi (https://www.example.com) käyttämään seuraavaa CSP-otsikkoa:

Verkkosivuston CSP-otsikko (https://www.example.com):

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

              
                Copy
              
            
          

Tämä CSP-politiikka sallii verkkosivuston ladata skriptejä ja muodostaa yhteyden API:in, mutta estää sitä lataamasta skriptejä tai muodostamasta yhteyttä muihin verkkotunnuksiin.

Yhteenveto

Sisällön turvallisuuspolitiikka (CSP) ja Cross-Origin Resource Sharing (CORS) ovat välttämättömiä työkaluja front-end-sovellustesi tietoturvan vahvistamiseen. Määrittämällä CSP:n ja CORSin huolellisesti voit merkittävästi vähentää XSS-hyökkäysten, datan syöttöhyökkäysten ja muiden tietoturvahaavoittuvuuksien riskiä. Muista aloittaa rajoittavalla politiikalla, testata perusteellisesti ja jatkuvasti valvoa ja hienosäätää asetuksiasi sopeutuaksesi sovelluksesi muutoksiin ja kehittyvään uhkaympäristöön. Priorisoimalla front-endin tietoturvan voit suojata käyttäjiäsi ja varmistaa verkkosovellustesi eheyden nykypäivän yhä monimutkaisemmassa digitaalisessa maailmassa.