Content Security Policy (CSP, "sisällön suojauskäytäntö") on selaimen turvakontrolli, jonka verkkosivut voivat vapaaehtoisesti ottaa suojakseen lähettämällä Content-Security-Policy -otsakkeen HTTP-vastauksissaan.

CSP:n perus toimintaperiaate on lisätä verkkosivun turvallisuutta rajoittamalla mitä sivustolla saa tapahtua ja mistä sivustolle saa ladata resursseja, kuten skriptejä.

CSP on siis selainpuolen toteutus vähimmäisen oikeuden periaatteesta (principle of least privilege), eli annetaan selaimelle vain välttämättömät oikeudet, jolloin hyökkäyksen sattuessa hyökkääjällä on mahdollisimman rajatut oikeudet aiheuttaa vahinkoa.

Sivun alalaidassa on kymmenen labraa joissa pääset harjoittelemaan CSP:n käyttöä käytännössä erilaisissa tilanteissa!

 vastaan, mutta tehokkaan suojan saadakseen, CSP pitää tehdä oikein.

Lisäksi CSP voi suojata muita XSS:n kaltaisia hyökkäyksiä vastaan, jossa yritetään ladata esimerkiksi tyylejä (CSS:ää), joka ei kuulu web-sovellukseen.

Lopulta CSP:llä on mahdollista suojata joitakin kehystyshyökkäyksiä (kuten clickjacking) vastaan rajaamalla, että mitkä (jos mitkään) ulkoiset sivustot saavat kehystää sivun (esim. IFRAME-elementillä).

XSS-suojaus on kuitenkin CSP:n pääasiallinen tarkoitus.

Mitä XSS (Cross-Site Scripting)-hyökkäykset sitten ovat?

XSS on yleistermi haavoittuvuuksille, jotka johtavat siihen, että hyökkääjä saa sovelluksen selaimen päässä suoritettavaan (JavaScript) -koodiin tehtyä haitallisia muutoksia. Haavoittuvuus on käsitelty laajemmin Hakatemian 

, mutta tässä on yksinkertainen esimerkki.

Oletetaan, että sivustolla on tällainen hakutoiminnallisuus: 

Toiminnallisuus on haavoittuva XSS-hyökkäyksille koska sovellus rakentaa HTML:ää turvattomasti. Url-parametri 

 asetetaan suoraan osaksi HTML-merkkijonoa, jolloin pääsee muuttamaan HTML:n rakennetta.

Hyökkääjän on mahdollista hyödyntää haavoittuvuutta rakentamalla sovellukseen seuraavanlaisia linkkejä: 

Kun uhrin avaa linkin, sovellus rakentaa turvattomasti HTML-vastauksen joka lähetetään uhrin selaimeen seuraavanlaisena: 

 sijasta hyökkääjä toki tekisi jotain muuta kuten varastaisi käyttäjän tietoja tai suorittaisi sovelluksessa ei-haluttuja toimintoja.

XSS-haavoittuvuus

Miten CSP sitten käytännössä suojaa XSS-haavoittuvuuksia vastaan?

Otetaan käytännön esimerkkinä Hakatemian nettisivut. Ladataan sivu ja simuloidaan hyökkäys lisäämällä koodi 

HTTP-vastaukseen käyttämällä BurpSuite -työkalua.

"XSS" alert-ikkunaa ei kuitenkaan ilmesty. Miksi? - Vastaus löytyy selaimen konsolista. Hakatemian CSP estää hyökkäyksen, koska se ei salli tämän kaltaisia inline-skriptejä.

Käytännössä CSP toimii niin, että web-palvelin palauttaa HTTP-vastauksessaan (

 -otsakkeessa) politiikan, joka määrittää esimerkiksi, että minkälaisia resursseja sivusto saa ladata tai suorittaa.

Selain sitten tulkitsee tätä säännöstöä aina, kun sivustollasi tapahtuu joku CSP:n tukema toiminto, ja joko sallii sen tai kieltää sen. Kieltämisestä ilmestyy punaista herjaa selaimen konsoliin sekä raportti CSP-raportinkäsittelijääsi, jos olet ottanut sellaisen käyttöön

 direktiivillä (tästä myöhemmin lisää).

. Yllä olevassa esimerkissä on kaksi direktiiviä: Skriptien rajoitus (

Direktiivit on erotettu toisistaan puolipisteellä (;) ja sisältävät lähteitä, joista kyseistä resurssia voi ladata.

Kaikille resursseille, joita CSP voi rajoittaa on oma direktiivi.

Jos direktiiviä ei ole asetettu ollenkaan

, resurssia ei ole rajoitettu mitenkään. Tämä on oletustila kaikilla verkkosivuilla.

, resurssi on lähtökohtaisesti kokonaan estetty ja pelkästään direktiivissä listatut lähteet on sallittuina.

 direktiivit saavat arvon siitä, jos ei niitä ole asetettu suoraan.

Tietyt direktiiveissä listatut lähteet syrjäyttävät toiset lähteet.

 avainsanan, että URL-pohjaiset sallimiset. Palataan siihen, mitä nämä tarkoittavat hieman alempana.

Näin rajoitat JavaScript -koodin suoritusta sivulla

CSP:n eittämättä tärkein tehtävä on rajoittaa JavaScript -koodin suorittamista verkkosivustolla. Tarkoitus on sinänsä yksinkertainen: Sallitaan kaikki JavaScript-koodi, joka sivustolla on tarkoitus suorittaa ja estetään kaikki muu.

Toteutus voi olla joko helppo tai sitten se voi vaatia hieman kikkailua ja muutoksia suojattavaan sovellukseen.

CSP:n eri direktiivien ja niiden vaikutusten toisiinsa ymmärtäminen on välttämätöntä tehokkaan CSP:n laatimiseen.

Katsotaan seuraavaksi, miten skriptien rajoitus tyypillisesti tehdään.

Aloita rajaamalla skriptit joko kokonaan pois tai sallimalla ne vain omasta domainista

Jos sovelluksesi lataa skriptejä omalta palvelimeltaan (useimmat sovellukset tekevät) niin voit sallia sen seuraavasti: 

Jos sovelluksesi ei lataa skriptejä omalta palvelimelta lainkaan, voit estää skriptit lähtökohtaisesti kokonaan.

Huomaa, että hipsut ovat tärkeitä. CSP:ssä 

 (ilman hipsuja) tarkoittaa URL-osoitetta, joka alkaa sanalla "none".

Skriptin salliminen URL-osoitteen perusteella

Jos haluat sallia tietyn skriptin Internetistä tai vaikkapa kaikki skriptit tietystä osoitteesta, voi sen tehdä URL-pohjaisella sallimisella. Huomaa, että 'hipsuja' ei käytetä URL-pohjaisessa sallimisessa.

Tietyn skriptin salliminen https://cdn.example.com osoitteesta

Kaikkien skriptien salliminen https://cdn.example.com osoitteesta

Skripten salliminen mistä tahansa HTTPS-osoitteesta: 

Inline-skriptien salliminen CSP:llä turvallisesti

Jos sovelluksesi käyttää inline-skriptejä ja et pääse tai halua niistä eroon, CSP tarjoaa niiden sallimiseen kaksi täysin turvatonta ja kaksi kohtuullisen turvallista tapaa.

Inline-skripteillä tarkoitetaan CSP:n kontekstissa käytännössä, mitä tahansa, mitä hyökkääjä voisi ujuttaa HTML:n sekaan, joka suorittaisi skriptin suoraan.

Tyypillisin esimerkki inline-skriptistä on script-tagi, jonka sisällä on JavaScript-koodia: 

CSP laskee inline-skripteiksi kuitenkin laajan kirjon muitakin XSS-vektoreita, kuten JavaScript event handlerit (

Olla määrittämättä script-src rajoitusta ollenkaan.

joka siis nimensä mukaisesti sallii turvattomasti inline-skriptit ja tekee koko CSP:stä hyödyttömän.

 avainsanasta on, että sen käyttö ei itseasiassa ole aina väärin vaan se on tärkeä osa CSP:n yhteensopivuutta vanhempien selainten kanssa, mutta palataan tähän myöhemmin.

: Inline-skripti sallitaan esimerkiksi skriptin sisällön SHA256-tiivisteen perusteella.

: Inline-skripti (tai ulkoinenkin skripti) sallitaan joka sivun latauksessa uudelleen generoitavalla satunnaisen arvon perusteella joka annetaan atribuuttina script-tageille. Tämä dynaaminen tapa vaatii juuri tietynlaisen, perinteisen mallisen web-sovelluksen, jossa HTML rakennetaan palvelimen päässä jokaisella sivun latauksella.

Inline-skriptien salliminen tiivisteellä (hash)

Inline-skriptin salliminen esimerkiksi SHA256-tiivisteellä on melko yksinkertaista. Palauta vain

 -direktiivissä seuraavanlainen avainsana: 

Mistä saat Base64-arvon skriptin sisällön SHA256-tiivisteestä? - Helpoin tapa on antaa Google Chrome -selaimen tehdä työ puolestasi. Toimi seuraavasti: 

Aseta (paikallisessa kehitysympäristössäsi) CSP-otsake, joka estää inline-skriptit kokonaan, esimerkiksi 

Varmista, että skripti, jonka haluat sallia on sivustolla.

Lataa sivu Google Chrome -selaimessa. Skripti ei suoridu, koska CSP estää sen. Avaa nyt konsoli ja etsi CSP-virheilmoitus, joka esti skriptin. Virheilmoituksessa on mukana valmiiksi laskettu Base64-SHA256 skriptistä, jonka voit sellaisenaan lisätä 

Kuvat ovat yhdestä sivun alalaidasta löytyvästä harjoituksesta.

Tärkeä huomio tiivisteistä ja taaksepäin yhteensopivuudesta

lakkaa automaattisesti olemasta voimasta. Toisin sanoen 

 avainsanan. Tämä on tärkeää, koska todella vanhat selaimet eivät tue 'sha256'-avainsanaa, joten kannattaa lisätä myös '

, jos käytät tiivisteitä, ettei sivusto hajoa vanhoilla selaimilla.

Inline-skriptien salliminen satunnaisella tunnisteella (noncella)

Oletetaan, että sivustolla on tällainen hakutoiminnallisuus: 

```php
echo "<p>Search results for: " . $_GET('search') . "</p>"
```



Toiminnallisuus on haavoittuva XSS-hyökkäyksille koska sovellus rakentaa HTML:ää turvattomasti. Url-parametri **search** asetetaan suoraan osaksi HTML-merkkijonoa, jolloin pääsee muuttamaan HTML:n rakennetta.

Hyökkääjän on mahdollista hyödyntää haavoittuvuutta rakentamalla sovellukseen seuraavanlaisia linkkejä: 

```html
https://www.example.com/?search=<script>alert('XSS')</script>
```



Kun uhrin avaa linkin, sovellus rakentaa turvattomasti HTML-vastauksen joka lähetetään uhrin selaimeen seuraavanlaisena: 

```html
<p>
  Search results for:
  <script>
    alert('XSS')
  </script>
</p>
```

Koodin **alert('XSS')** sijasta hyökkääjä toki tekisi jotain muuta kuten varastaisi käyttäjän tietoja tai suorittaisi sovelluksessa ei-haluttuja toimintoja.

Sinulla on tällainen nappi etkä voi tai halua refaktoroida sitä muotoon jossa inline-tapahtumankäsittelijää ei tarvittaisi.

```html
 <button onclick="alert('Hello!')">
```

Sen sijaan, että vähentäisit merkittävästi turvallisuutta lisäämällä **'unsafe-inline' **avainsanan **script-src** -direktiiviin,  voit käyttää **'unsafe-hashes'** avainsanaa yhdessä tiivisteen kanssa joka sallii funktion, seuraavasti:

```yaml
script-src 'unsafe-hashes' 'sha256-0KAUGUNSAE9SmnRfyY+2MhbftgtqjBwh4sNjtk8aJKM='
```



Tiivisteen saat vaikka [report-uri ](https://report-uri.com/home/hash)palvelusta.

![](sanity:image-d1b5c745c0a344751bac993a04fe12c4afa7482f-1408x496-png)

'unsafe-hashes'

Oletetaan että meillä on GTM (Google Tag Manager) käytössä ja tarkoitus on antaa kaikkien GTM:n sivulle lataamien skriptien suorittua.

Aloitetaan lisäämällä GTM-skripti sivulle.

```html

<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;var n=d.querySelector('[nonce]');
n&&j.setAttribute('nonce',n.nonce||n.getAttribute('nonce'));f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXX');</script>

```



Avataan sitten sivu, katsotaan tiiviste Google Chrome -selaimen konsoliin ilmestyneestä herjasta ja sallitaan skripti sitten **script-src** -direktiivissä. Nyt skripti suoriutuu mutta se ei vielä saa ladata sivulle lisää skriptejä.

Tätä varten lisätään script-src -direktiiviin myös **'strict-dynamic' **-avainsana. Nyt valmiiksi luotettu skripti saa ladata vapaasti lisää skriptejä sivulle.

GTM tarvitsee myös **'unsafe-eval'** avainsanan toimiakseen.

Lopuksi lisätään **'unsafe-inline' **ja **https:** jotta sivusto toimisi edelleen myös hyvin vanhoilla selaimilla.

```yaml
script-src 'sha256-abcdefg' 'strict-dynamic' 'unsafe-inline' 'unsafe-eval' https:
```

GTM-salliminen tiivisteellä ja 'strict-dynamic' avainsanalla

Oletetaan että haluat ladata tyylejä omasta alkuperästä sekä https://cdn.example.com osoitteesta, voisit tehdä seuraavanlaisen politiikan.

```yaml
style-src 'self' https://cdn.example.com/
```

style-src

Voi ei! Joku on hakkeroinut verkkosivuston ja lisännyt sivulle haitallisen skriptin. Osaatko korjata CSP:n estääksesi skriptin suorittamisen ja pitääksesi muun verkkosivuston toiminnassa? Estä samalla koiran kuvan näkyminen, mutta pidä kissa.

CSP Haaste - Taso 1

Voi ei! Joku on hakkeroinut verkkosivuston ja lisännyt sivulle haitallisen skriptin. Osaatko korjata CSP:n estääksesi skriptin suorittamisen, sallien silti sivulle kuuluvan upotetun skriptin suorittamisen?

CSP Haaste - Taso 2

Voi ei! Joku on hakkeroitunut verkkosivuston ja lisännyt sivulle kolme haitallista skriptiä, yhden inline-skriptinä suoraan sivulle, toisen internetistä ja kolmannen sovelluksen omasta verkkotunnuksesta! Osaatko korjata CSP:n estääksesi pahantahtoisten skriptien suorituksen ja silti pitää muun verkkosivuston toiminnallisena? Ennen kaikkea oletetaan, ettet tiedä, mitä skriptejä legitiimi inline-skripti tuo mukanaan (kuten usein tapahtuu kolmannen osapuolen skripteissä, esimerkiksi Google Tag Manager), joten sen tulisi pystyä lataamaan mitä tahansa skriptejä Internetistä.

CSP Haaste - Taso 3

Voi ei! Lähetit CSP-otsikon, jonka rakensit tasolla 3, QA-tiimille, ja he sanoivat, että se rikkoi täysin verkkosivuston vanhoilla selaimilla! Osaatko korjata CSP:n lisäämällä taaksepäin yhteensopivuuden vanhoille selaimille?

CSP Haaste - Taso 4

Voi ei! Joku on hakkeroitunut verkkosivuston ja injektoinut väärennetyn kirjautumislomakkeen sivulle. Se lähettää käyttäjän tunnistetiedot hyökkääjän palvelimelle. Osaatko korjata CSP:n estääksesi lomakkeen lähettämisen?

CSP Haaste - Taso 5

Voi ei! Joku on hakkeroitunut verkkosivuston ja injektoinut base-tagin sivulle. Se muuttaa sivun perus-URL:ää, ohjaten kaikki linkit hyökkääjän sivulle. Osaatko korjata CSP:n estääksesi base-tagin käytön? Samalla voit estää kehykset ulkoisista lähteistä ja estää perinteisten HTML-elementtien, kuten embed tai object, käytön sivulla. Sinulla saattaa olla ongelmia CSP:n päivityksen kanssa väärennetyn base-tagin vuoksi. Ehkäpä sinun tulisi käyttää selaimen kehittäjätyökaluja poistaaksesi base-tagin sivulta ennen päivityslomakkeen lähettämistä?

CSP Haaste - Taso 6


Voi ei! Joku on hakkeroitunut verkkosivuston ja injektoinut CSS-tiedoston, joka tekee kaikesta näyttämään 90-luvun verkkosivulta. Osaatko korjata CSP:n estääksesi CSS-tiedoston lataamisen?

CSP Haaste - Taso 7

Voi ei! Joku on hakkeroitunut verkkosivuston ja injektoinut kirjastokortin tiedot keräävän skriptin sivulle, joka lähettää asiakkaiden kirjastokorttitiedot hyökkääjän palvelimelle. Osaatko korjata CSP:n estääksesi HTTP-yhteyden muodostamisen hyökkääjän palvelimeen?

CSP Haaste - Taso 8

Voi ei! Turvatiimi on ilmoittanut, että verkkosivusto on altis clickjacking-hyökkäyksille. Osaatko korjata CSP:n estääksesi verkkosivuston latautumisen iframeen?

CSP Haaste - Taso 9

Viimeinen haaste. Sinut palkataan yritykseen toteuttamaan tiukka, taaksepäin yhteensopiva Content Security Policy (CSP) heidän verkkosivustolleen. Onnistutko siinä?

CSP Haaste - Taso 10

Content Security Policy (CSP)

Selain on monipuolinen ympäristö, jossa on eri välilehdissä ja eri ikkunoissa ajossa koodia täysin eri tahoilta, ja nämä web-sovellukset pystyvät vielä kommunikoimaan keskenään. Tällaisessa ympäristössä on riskinsä!

Käydään kurssilla läpi selainpuolen hyökkäyksiä ja ennen kaikkea suojakeinoja.

Content Security Policy (CSP)

Mikä on CSP?

Hakkeroinnin oppiminen alkaa tästä