Jari-Pekka Voutilainen Tietoturva Ajaxia hyödyntävissä

Jari-Pekka Voutilainen
Tietoturva Ajaxia hyödyntävissä verkkosovelluksissa
Kandidaatintyö
Tarkastaja: Henri Hansen
II
TIIVISTELMÄ
TAMPEREEN TEKNILLINEN YLIOPISTO
Tietotekniikan koulutusohjelma
Jari-Pekka Voutilainen: Tietoturva Ajaxia hyödyntävissä verkkosovelluksissa
Kandidaatintyö, 18 sivua, 0 liitesivua
Huhtikuu 2010
Pääaine: Ohjelmistotekniikka
Tarkastajat: Henri Hansen
Avainsanat: JavaScript, Ajax, XSS, CSRF
Toimivia verkkosovelluksia on helppo ja nopea tehdä. Käyttäjä availee linkkejä ja lähettelee lomakkeita ja saa vastauksena uusia verkkosivuja. Turvallisen verkkosovelluksen tekeminen on huomattavasti vaikeampaa ja Web 2.0:n mukana tullut Ajax tekee tästä
vielä hankalampaa. Ajax on teknologia-kokoelma, jolla ratkaistaan perinteisten verkkosovellusten ongelmia, kuten samojen melkein samanlaisten sivujen uudelleenlataus ja sovelluksen käytön pysäytys pyynnön käsittelyn ajaksi. Mutta nämä samaiset teknologiat
paljastavat palvelimen toimintalogiikkaa ja verkkopalveluita hyökkääjälle ja siten helpottavat hyökkäämistä.
Jotta verkkosovelluksesta saadaan turvallinen, pitää lähteä lähtökohdasta, että käyttäjään ei voi luottaa. Kaikki käyttäjän tuottama sisältö pitää validoida ja joko hyväksyä,
hyväksyä riisuttuna tai hylätä kokonaan. Ajaxin paljastama toimintalogiikka pitäisi minimoida ja kriittisiä osia ei saisi paljastaa ollenkaan. Lisäksi tietoturvaa pitäisi testata
määrittelemättömän toiminnallisuuden varalta.
III
SISÄLLYS
1. Johdanto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Ajax ja sen luomat tietoturvallisuusongelmat . . . . . . . . . . . .
2.1 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Asynkroninen . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Tietoturvaongelmien yleisyys . . . . . . . . . . . . . . . . .
3. Verkkosovellusta vastaan hyökkääminen . . . . . . . . . . . . . . .
3.1 Perinteinen verkkosovellus . . . . . . . . . . . . . . . . . . .
3.1.1 Resurssien luettelointi . . . . . . . . . . . . . . . . . . .
3.1.2 Parametrien manipulointi . . . . . . . . . . . . . . . . .
3.1.3 Muut hyökkäykset . . . . . . . . . . . . . . . . . . . . .
3.2 Ajax verkkosovellus . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Syötekentät . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Verkkopalvelut . . . . . . . . . . . . . . . . . . . . . .
4. Tekniikoita tietoturva-aukkojen vähentämiseen verkkosovelluksissa
4.1 JavaScriptin turvamekanismit . . . . . . . . . . . . . . . . .
4.2 Chromium-selaimen tietoturva-arkkitehtuuri . . . . . . . . .
4.3 Turvallinen verkkosovellus . . . . . . . . . . . . . . . . . . .
5. Ajax-sovellusten tietoturvan testaus . . . . . . . . . . . . . . . . .
6. Yhteenveto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lähteet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
3
3
3
4
5
5
6
6
6
7
8
9
9
10
11
11
12
13
16
18
19
IV
TERMIT JA SYMBOLIT
• JSON eli JavaScript Object Notation. Serialisointitekniikka, jota käytetään datan
siirtämiseen palvelimen ja asiakkaan välillä.
• XML eli Extensible Markup Language. Rakenteellisen tiedon esitystekniikka.
• DOM eli Document Object Model. Alusta- ja kieliriippumaton käytäntö
HTML:n, XHTML:n ja XML:n vuorovaikutukseen.
• HTML eli HyperText Markup Language. Kieli verkkosivujen rakenteen toteutukseen.
• CSS eli Cascading Style Sheet. Kieli verkkosivujen tyylin ja ulkoasun toteutukseen.
• SQL eli Structured Query Language. Kieli tietokantakyselyiden tuottamiseen.
1
1.
JOHDANTO
Verkkosovellukset ovat internetissä olevia sovelluksia, jotka reagoivat käyttäjän toimiin,
kuten linkkien klikkailemiseen ja lomakkeiden lähettämiseen. Verkkosovellukset toteutaan asiakas-palvelin-arkkitehtuurilla, jossa asiakkaana yleensä toimii käyttäjän selain.
Perinteisesti näissä sovelluksissa selain lähettää palvelimelle pyynnön, kun käyttäjä klikkaa linkkiä, palvelin käsittelee sen ja vastaa asiakkalle uudella verkkosivulla. Käsittelyn
ajan käyttäjä joutuu odottamaan, sillä perinteiset verkkosovellukset ovat synkronisia eli
käyttäjän klikatessa uutta linkkiä ennen kuin edellinen on käsitelty, selain unohtaa edellisen toiminnallisuuden. Synkronisuus aiheuttaa viiveitä palvelimen käsitellessä suurempia
datamääriä ja verkon yli siirretävän datan määrä kasvaa kun siirretään uusia verkkosivuja,
jotka toisinaan ovat jopa melkein samanlaisia edelliseen verkkosivuun verrattuna.
Web 2.0:n mukana tullut Ajax yrittää ratkaista perinteisten verkkosovellusten ongelmia.
Ajaxissa kokonaisia verkkosivuja ei haeta vaan verkkosovelluksiin haetaan sisältöä osittaisilla sivupyynnöillä asynkronisesti. Asynkroniset sivupyynnöt myös mahdollistaa käyttäjän toimimisen sovelluksessa, vaikka palvelin ei olisikaan vielä vastannut. Tämä tekee
sovelluksesta näennäisesti nopeamman ja mahdollistaa rikkaat internet sovellukset, jotka näyttävät työpöytäsovelluksilta. Tunnetuimpia Ajaxia hyödyntäviä verkkosovelluksia
ovat mm. Googlen GMail ja Docs sekä Facebook.
Vaikka Ajax ratkaisee monia verkkosovellusten ongelmia, se myös aiheuttaa niitä. Palvelimen hyökkäyspinta-ala kasvaa kun toimintalogiikkaa siirretään asiakkalle, Ajaxissa
käytettävät skriptikielet mahdollistavat haittaohjelmien ajamisen, joilla yritetään vuotaa
henkilökohtaisia tietoja, kuten tunnuksia ja salasanoja, kolmansille osapuolille. Oikeilla suunnitteluperiaatteilla näitä tietoturva-aukkoja voidaan vähentää jo toteutusvaiheessa,
jonka lisäksi sovelluksen tietoturvaa voidaan testata hyökkäämällä sitä vastaan.
Tässä kandidaatintyössä tutkitaan verkkosovellusten tietoturvaa ja kuinka Ajaxin käyttö siihen vaikuttaa. Tämä saavutetaan tutkimalla perinteisten verkkopalvelujen haavoittuvuutta, Ajaxin kasvattamaa hyökkäyspinta-alaa, suunnitteluperiaatteita haavoittuvuuksien
välttämiseen ja verkkosovellusten testaamista.
Luvussa 2 tutkitaan tarkemmin Ajaxia, sen tietoturvaa ja tietoturvaongelmien yleisyyttä. Luvussa 3 perehdytään kuinka perinteisiä verkkosovelluksia ja Ajax-sovelluksia vas-
1. Johdanto
2
taan hyökätään. Luvussa 4 tarkasteellaan tekniikoita tietoturvaongelmien ehkäisyyn suunnitteluperiaatteilla, Ajax-teknologioden omilla turvamekanismeilla ja kuinka Chroniumselain suojaa käyttäjää haittaohjelmilta. Luvussa 5 esitellään kuinka Ajax-sovelluksien
tietoturvaa testataan ohjelmallisesti. Lopuksi luvussa 6 on yhteenveto Ajaxin tietoturvasta
ratkaisuineen.
3
2.
AJAX JA SEN LUOMAT
TIETOTURVALLISUUSONGELMAT
2.1
Ajax
Perinteisessä verkkopalvelussa, kun selain tekee pyynnön palvelimelle, se pyytää kokonaista verkkosivua. Verkkopalvelu vastaa generoimalla kokonaisen HTML-kielisen verkkosivun ja palauttaa sen selaimelle. Selain reagoi tähän hylkäämällä entisen sivun ja korvaamalla sen uudella. Tämä hukkaa resursseja, sillä verkkopalvelu usein generoi sivuja, jotka ovat melkein identtisiä vanhan sivun kanssa. Lisäksi verkkoliikennettä hukataan
siirtämällä suuria melkein samanlaisia verkkosivuja uudestaan ja uudestaan, jonka ajan
käyttäjä joutuu odottamaan sivun latautumista.
Ajax on kokoelma teknologioita, joilla yritetään ratkaista perinteisen verkkopalvelun
ongelmia. Ajax mahdollistaa verkkosivun osittaisen päivittämisen reaaliaikaisesti ilman
että käyttäjän tarvitsee koskaan lähettää lomaketta tai edes lähteä verkkosivulta. Asiakaspuolen skriptikoodi (yleensä JavaScript) tekee asynkronisia kyselyitä noutaakseen verkkosivun paloja, jotka joko voidaan muuntaa HTML:ksi asiakaspäässä tai ne ovat valmista palvelimella generoitua HTML:ää. Kummassakin tapauksessa asiakaspään skripti muokkaa vastauksen perusteella dokumenttioliomallia (DOM) sisältämään uuden datan. Asynkronisuuden johdosta käyttäjä voi jatkaa verkkosivun käyttämistä vaikka vastaus palvelulta ei ole vielä saapunut. Ajax tulee sanoista Asynchronous JavaScript And
XML. Termin luojan Jesse James Garretin mielestä Ajax ei ole akronyymi, vaikka muun
maailman mielestä se on [1].
2.1.1
Asynkroninen
Tyypillisessä verkkopalvelussa on työpöytäsovellukseen verrattuna paljon enemmän viiveitä: selaimen täytyy käsitellä käyttäjän toiminta, kuten napin painaminen, käsittelyn
jälkeen pyyntö tehdään palvelimelle. Palvelin käsittelee pyynnön ja lähettää vastauksen,
johon selaimen on reagoitava. Kaikkeen tähän menee aikaa ja verkkotekniikasta johtuen,
myös ylimääräisiä viiveitä saattaa muodostua. Asynkronisuudella pyritään pienentämään
käyttäjälle näkyviä viiveitä. Tekemällä pienempiä kyselyitä, voidaan pienentää siirrettävän ja käsiteltävän datan määrää. Kun ei pysäytetä verkkopalvelun käyttöä pyynnön käsittelyn ajaksi, palvelu vaikuttaa käyttäjästä nopeammalta ja paremmin reagoivammalta.
2. Ajax ja sen luomat tietoturvallisuusongelmat
2.1.2
4
JavaScript
Ajaxissa asiakaspuolen skriptikoodia käytetään yhdistämään teknologiat toisiinsa. Vaikka
Ajax mahdollistaa myös muiden skriptikielien käyttämisen, kuten VBScriptin, JavaScript
on ylivoimaisesti suosituin kieli Ajaxin yhteydessä. Yksinkertainen verkkosivu, joka ottaa
käyttäjän syötteen, lähettää sen palvelimelle, joka vastaa samanlaisella sivulla, johon on
liitetty käyttäjän syöte, olisi seuraavanlainen.
<html >
<head>
< t i t l e >Yksinkertainen esimerkki</ t i t l e >
< / head>
<body>
<form a c t i o n = " i n p u t . php " method= "GET" >
S y ö t e t t y t e k s t i o l i : foo
<input type=" t e x t " / >
<input type=" submit " value=" P ä i v i t ä " / >
< / form>
< / body>
< / html >
Ohjelma 2.1: Perinteinen verkkosivu
Ajaxilla toteutettuna verkkosivu näyttää selaimessa täsmälleen samanlaiselta, mutta
kooditasolla se eroaa hyvinkin paljon. ”Päivitä”-nappi ei enää päivitä koko sivua, sen sijaan se lähettää syötetyn arvon palvelimelle ja päivittää sivusta vain syötetyn sanan esittävän osan palvelimen vastauksen perusteella. Vaikka näin pienessä ohjelmassa tämä vaikuttaa turhalta työltä, niin Ajaxin hyödyt tulevat esille suuremmissa sovelluksissa paljon
paremmin. Kooditasolla verkkosivu näyttää seuraavalta.
<html >
<head>
< t i t l e >Yksinkertainen esimerkki</ t i t l e >
< s c r i p t type=" t e x t / j a v a s c r i p t " >
v a r h t t p R e q u e s t = new XMLHttpRequest ( ) ;
function getInputValue () {
/ / läheteään syöte käyttäen ajaxia
v a r p a r a m s = document . g e t E l e m e n t B y I d ( ’ i n p u t V a l u e ’ ) . v a l u e ;
h t t p R e q u e s t . open ( "GET" , " i n p u t . php " + " ? " + params , t r u e ) ;
}
function handleInputChanged ( ) {
/ / l i s ä t ä ä n palvelimen vastaus s i v u l l e
v a r i n p u t S p a n = document . g e t E l e m e n t B y I d ( ’ i n p u t ’ ) ;
inputSpan . childNodes [ 0 ] . data = httpRequest . responseText ;
}
2. Ajax ja sen luomat tietoturvallisuusongelmat
5
</ script>
< / head>
<body>
S y ö t e t t y t e k s t i o l i : <span i d = " i n p u t " > f o o < / span >
<input type=" t e x t " id=" inputValue " / >
<input type=" submit " value=" P ä i v i t ä " onclick =" g e t I n p u t V a l u e ( ) ; " / >
< / body>
< / html >
Ohjelma 2.2: Ajaxilla varustettu verkkosivu
Koko lomakkeen lähettämisen sijaan ”Päivitä”-nappia painaessa kutsutaan
”getInputValue”-funktiota, joka lähettää kentän arvon palvelimelle ja vastauksen tullessa
”handleInputChanged”-funktio päivittää saadun arvon sivulle.
2.1.3
XML
XML täydentää Ajaxin teknologiat ja se on vähiten merkitsevin: JavaScript mahdollistaa osittaiset päivitykset, asynkronisuus tekee osittaisista päivityksistä kannattavia, mutta
XML on käytännössä vapaaehtoinen tapa rakentaa pyyntöjä ja vastauksia. XML:n sijasta
voidaan käyttää myös muita vaihtoehtoja tämän saavuttamiseen. Usein käytetään JSON:ia
(JavaScript Object Notation) ja edellisessä esimerkissä käytettiin selkokielistä vastausta,
joka päivitettiin sivulle sellaisenaan.
2.2
Tietoturvaongelmien yleisyys
JavaScript on skriptikieli, jolla on nopea toteuttaa verkkosovelluksien Ajax-ominaisuuksia, mutta JavaScriptissä on myös useita ominaisuuksia, jotka mahdollistavat tietoturvaaukkoja: mm. toimintalogiikan ylenpalttinen siirtäminen asiakkaalle, validointien puutteellinen toteuttaminen, eval-funktion käyttö, joka mahdollistaa merkkijonon tulkitsemisen JavaScriptiksi ja ulkopuolisten JavaScript-tiedostojen sisällyttäminen liian suurilla oikeuksilla. Nämä mahdollistavat hyökkääjän ilkeämielisen koodin injektoimisen
ja siten ajamisen. Yuen ja Wangin tutkimuksen mukaan[2] 66.4% tutkituista verkkosivuista sisällytti JavaScriptiä ulkopuolisista lähteistä täysillä oikeuksilla, 44.4% verkkosivuista käyttivät eval-funktiota JavaScriptin generoimiseen ja document.write-funktion
sekä innerHTML-ominaisuuden käyttö oli huomattavasti yleisempää dynaamiseen JavaScriptin generoimiseen kuin turvallisempien DOM-funktioiden käyttö. Näitä tietoturvaaukkoja luovia toteutusratkaisuja voidaan välttää perusteellisella suunnittelulla.
6
3.
VERKKOSOVELLUSTA VASTAAN
HYÖKKÄÄMINEN
Ajaxin arkkitehtuuri mahdollistaa uusia hyökkäystapoja, mutta perinteiset tietoturvaongelmat ovat edelleen pääasiallinen hyökkäystapa myös Ajax-sovelluksissa. Hyökkääjät
voivat käyttää olemassa olevia hyökkäystekniikoita ja Ajax-arkkitehtuuri tekee niistä tehokkaampia. Ajax-sovelluksen turvaaminen vaatii myös perinteisten tietoturvaongelmien
ymmärtämisen.
3.1
Perinteinen verkkosovellus
Hyökkäystekniikat perinteisissä verkkosovelluksissa jaetaan kahteen pääkategoriaan: resurssien luettelointi ja parametrien manipulointi. Lisäksi Cross Site Request Forgery
(CSRF), verkkourkinta (eng. phishing) ja kolmannen kategorian muodostavat palvelunestohyökkäykset.[1]
3.1.1
Resurssien luettelointi
Resurssien luettelointi on yksinkertaisimmillaan arvailua, jotta löydettäisiin sisältöä, joka
on palvelimella, mutta sitä ei ole julkisesti mainostettu. Tälläistä sisältöä voidaan noutaa,
kun käyttäjä pyytää oikeaa URLia, vaikka siihen ei ole yhtään linkkiä koko verkkosovelluksessa. Esimerkiksi tiedosto readme.txt hakemistossa bar. Verkkosivustolla foo.com
ei ole yhtään linkkiä tiedostoon readme.txt, mutta se voidaan noutaa, jos käyttäjä pyytää
URLia http://foo.com/bar/readme.txt.
Yksinkertaisin resurssien luettelointi -hyökkäys on arvailla yleisesti käytössä olevia
hakemistojen ja tiedostojen nimiä. Tätä kutsutaan sokeaksi resurssien luetteloinniksi, koska hyökkääjällä ei ole mitään lähtökohtaa verkkosivulla, jonka perusteella yrittää jotain
tiettyä nimeä. Hyökkääjä yrittää tiedostojen niminä esimerkiksi install.txt, whatsnew.txt
ja faq.txt. Näitä tiedostonimiä koitetaan useaan hakemistoon kuten admin ja test. Täydellinen lista, joita hyökkääjä käyttää, sisältää satoja tiedosto- ja hakemistonimiä. Sokea
luettolointi on tehokasta, koska kehittäjät seuraavat käytäntöjä: kehittäjä nimeää tiedostot
samanlailla kuin kaikki muutkin kehittäjät.
Kehittyneempää luettelointitekniikkaa kutsutaan tietoon perustuvaksi resurssien luetteloinniksi. Tekniikan kokeilemat resurssien nimet perustuvat verkkosovelluksessa olevien
3. Verkkosovellusta vastaan hyökkääminen
7
tiedostojen nimiin. Esimerkiksi jos verkkosovelluksessa on tiedosto checkout.php, hyökkääjä kokeilee checkout.bak, checkout.old ja checkout.tmp nimisiä tiedostoja. Jos kehittäjältä on jäänyt tälläsiä tiedostoja palvelimelle, hyökkääjä voi saada koko verkkosivun
lähdekoodin.
Tietoon perustuvaa resurssien luettelointia voidaan käyttää myös parametrien arvoihin.
Hyökkääjä tietää, että verkkosovelluksessa on sivu nimeltä product.aspx ja että sivu ottaa
parametrina id:n. Hyökkääjä tallentaa koko verkkosivuston käyttämällä Web Crawleria ja
huomaa, että id:t ovat positiivisia nelinumeroisia lukuja välillä 1000-2500. Hän huomaa
myös että vaikka mahdollisia sivuja kyseisellä välillä on 1500 kpl, crawler tallensi vain
1200 sivua. Puuttuvat id:t hyökkääjä voi helposti päätellä ja yrittää hakea niitä vastaavat
sivut, jotka jostain syystä on jätetty linkkien ulkopuolelle.
3.1.2
Parametrien manipulointi
Hyökkääjät tyypillisesti muokkaavat selaimen ja verkkosovelluksen välillä liikkuvaa dataa saadakseen sovelluksen tekemään jotain mihin sitä ei ole suunniteltu. Tätä kutsutaan
parametrien manipuloinniksi. Näitä hyökkäyksiä yritetään sovelluksen reunakohtiin joita kehittäjä ei ole huomioinut ja näin saavat sovelluksen toimimaan väärin. Esimerkiksi
sovelluksessa pyydetään postinumeroa ja hyökkääjä syöttää arvon -1. Jos kehittäjä ei huomioi virheellistä arvoa, hyökkääjä voi saada tietoa sovelluksesta poikkeuksen muodossa.
Tyypillisin parametrien manipulointihyökkäys on SQL-injektio. Siinä parametrin arvoksi annetaan SQL käskyjä, hyökkääjän toivoessa että käskyt ajetaan tietokantaan puutteellisen validoinnin vuoksi. Aikaisemmassa esimerkissä oli /product.aspx?id=1000, josta palvelin muodostaa seuraavan SQL-lauseen.
SELECT d e s c r i p t i o n FROM P r o d u c t s WHERE i d = 1000
Hyökkääjä testaa onko sovelluksessa tietoturva-aukko tekemällä pyynnön osoitteeseen
/product.aspx?id=’, jolloin palvelin muodostaa kyselyn:
SELECT d e s c r i p t i o n FROM P r o d u c t s WHERE i d = ’
Jos palvelin vastaa hyökkääjälle tietokannan virheviestillä, hyökkääjä tietää että sovelluksessa on tietoturva-aukko ja voi ajaa omia käskyjään tietokantaan. Esimerkiksi noutaa
tietokannan sisältöä tekemällä kyselyn:
/ p r o d u c t . a s p x ? i d = 1 UNION SELECT name FROM s y s o b j e c t s WHERE x t y p e = ’U
’ AND name > ’ t b l _ g l o b a l s ’
Toinen hyvin yleinen parametrien manipulointihyökkäys on Cross-Site Scripting (XSS).
Toisin kuin SQL-injektiossa, XSS-hyökkäyksessä tarkoituksena on saada ajettua hyökkääjän koodi palvelimen sijaan kohteen selaimessa. XSS-aukkoja muodostuu kun käyttäjän syöte näytetään sellaiseen palautettavalla verkkosivulla, esimerkiksi hakutuloksissa ja
3. Verkkosovellusta vastaan hyökkääminen
8
keskustelufoorumeilla.
XSS-hyökkäykset jaetaan kolmeen kategoriaan[3]: peilatut, pysyvät ja DOM-pohjaiset
hyökkäykset. Peilatuissa hyökkäyksissä hyökkääjän injektoima koodi annetaan pyynnön
parametrina ja huijataan käyttäjä pyytämään kyseistä URLia esimerkiksi sähköpostissa
sosiaalisen manipuloinnin keinoin.
Pysyvässä hyökkäyksessä hyökkääjän koodi talletetaan palvelimelle, esimerkiksi wikiin tai blogiin, johon voi tallentaa kommentteja. Tämän tyyppinen hyökkäys on käyttäjälle peilattua hyökkäystä vaarallisempi, sillä se ei vaadi sosiaalista manipulointia, riittää
että käyttäjä avaa sivun, johon hyökkääjän koodi on talletettu.
DOM-pohjaisessa hyökkäyksessä aukko perustuu käyttäjän antaman syötteen kirjoittamiseen DOMiin, esimerkiksi käyttäjän nimi näytetään sivulla ystävällisessä Tervetuloailmoituksessa. Jos syötteeksi annetaan hyökkäyskoodia, se kirjoitetaan DOMiin ja ajetaan.
3.1.3
Muut hyökkäykset
Resurssien luetteloinnin ja parametrien manipuloinnin lisäksi on muita hyökkäyksiä, jotka
eivät sovi kumpaankaan kategoriaan. Näitä ovat mm. Cross-Site Request Forgery (CSRF),
verkkourkinta ja palvelunestohyökkäykset.
CSRF-hyökkäyksessä tarkoituksena on tehdä petoksellisia pyyntöjä palvelimelle käyttäen uhrin tunnistautumistietoja. CSRF-hyökkäys on samankaltainen kuin XSS-hyökkäys,
molemmissa tarkoituksena on ajaa ilkeämielisiä toimintoja. Erona näissä on luottamuksen väärinkäyttö. XSS-hyökkäyksessä käyttäjä luottaa, että kaikki sisältö verkkosivulla on
tarkoituksen mukaista ja sivun kehittäjän sivulle pistämää. CSRF-hyökkäyksessä verkkosovellus luottaa siihen että kaikki käyttäjän toiminnat ovat tarkoituksella tehtyjä käyttäjän
toimesta. Esimerkiksi pankkisovellus, jossa voi tehdä 1000 euron tilisiirron tilille 1234
pyynnöllä
/manageAccount.php?transferTo=1234&amount=1000 kunhan käyttäjä on autentikoitu.
Tätä luottamusta on helppo hyväksi käyttää esimerkiksi käyttäjän vieraillessa ilkeämielisellä verkkosivulla, jossa on kuvalinkki <img src=http://www.bank.com/
manageAccount.php?transferTo=5678&amount=1000/>, pankkisovellus tekee tilisiirron
käyttäjän tietämättä jos käyttäjä on autentikoitunut.
Verkkourkinnassa (eng. phishing) käyttäjiä huijataan verkkosivustoilla, jotka näyttävät
samalta kuin käyttäjien normaalisti käytettävät verkkosivut. Näillä sivustoilla yritetään
urkkia käyttäjätunnuksia, salasanoja tai muita henkilökohtaisia tietoja. Useimmat selaimet sisältävät tänä päivänä mustan listan, johon on talletettu tunnettuja urkintasivustoja,
mutta tämä alkaa olemaan vanhentunut menetelmä, koska hyökkääjät käyttävät kehittyneempiä hyökkäyksiä kuten XSS:ää, jolloin musta lista ei huomaa urkintaa.
3. Verkkosovellusta vastaan hyökkääminen
9
Palvelunestohyökkäyksissä hyökkääjä lähettää niin paljon kyselyitä että palvelin ei
ehdi käsittelemään kaikkea, jolloin palvelin sammuttaa verkkosovelluksen. Hyökkääjän
kannalta tämä ei vaadi paljoakaan, koska kyselyiden tekeminen on helppoa, mutta palvelin voi kuluttaa viisinkertaisen ajan kyselyn käsittelyyn.
3.2
Ajax verkkosovellus
Ajaxia hyödyntävissä verkkosovelluksissa on laajempi hyökkäyspinta-ala. Kun perinteisessä verkkosovelluksessa voidaan hyökätä vain syötekenttään, Ajaxin käyttöönotto kasvattaa hyökkäyspinta-alan sisältämään myös syötekentän käsittelevän verkkopalvelun.
3.2.1
Syötekentät
Perinteisessä verkkopalvelussa hyökkäykset tapahtuvat syötekenttiä vastaan. Näitä ovat
mm. ilmiselvät lomakkeiden syötteet, evästeet, otsakkeet, palvelimelle lähetettävien kyselyiden parametrit ja palvelimen hyväksymät käyttäjän omat tiedostot.
Lomakkeiden näkyvät kentät ovat helpoin hyökkäyskohde, koska ne todennäköisesti
käsitellään palvelimella. Näkyviä kenttiä vastaan on myös helppo hyökätä, koska kaikki
lomakkeen näkyvät kentät renderöidään selaimeen ja hyökkääjä voi kirjoittaa hyökkäyksensä suoraan lomakkeeseen.
Evästeisiin yleensä tallennetaan istunnon identifikaatio tai autentikoinnin tunnus. Nämä lähetetään käyttäjän koneelle ja selain lähettää ne palvelimelle jokaisella sivupyynnöllä. Vaikka evästeet ovat palvelimen generoimia riippumatta käyttötarkoituksesta, mikään
ei estä hyökkääjää muokkaamasta evästettä, joka lähetetään takaisin palvelimelle. Siispä
myös evästeiden sisältö pitää aina käsitellä palvelimella kuin se olisi käyttäjän syöttämä.
Otsakkeet (eng. headers) ovat selaimen generoimia, joihin käyttäjä ei voi suoraan vaikuttaa. Hyökkääjät kuitenkin voivat muilla ohjelmilla kuin selaimella tehdä omia otsakkeita tai muokata selaimen lähettämiä ja siten, jos verkkosovellus käsittelee otsakkeita,
nekin pitää käsitellä siten kuin ne olisi käyttäjän tekemiä syötteitä.
Lomakkeiden piilokentät ovat kuten evästeet ja otsakkeet, niillä ei ole graafista esitysmuotoa mutta käyttäjä voi määritellä ne itse selaimen ulkopuolella. Verkkosovellus ei siis
saa luottaa että piilokentät olisivat samat kuin sivua luotaessa.
Palvelimelle lähetettävissä kyselyissä olevat parametrit ovat myös käyttäjän syötteitä
ja nämä voivat olla avoimia SQL-injektioille. Normaalin datan välittämisen lisäksi, parametrejä käytetään toisinaan istunnon seuraamiseen ilman evästettä. Tämä istunnon tunnisteen lisääminen parametrilistaan avaa aukon hyökkääjälle esiintyä toisena käyttäjänä,
jos hyökkääjä saa tunnisteen tietoonsa. Lisäksi usein kehittäjät unohtavat takaovia ominaisuuksiin joihin normaaleilla käyttäjillä ei pitäisi olla pääsyä. Esimerkiksi parametrillä
3. Verkkosovellusta vastaan hyökkääminen
10
debug=on, sovellus antaisi ylimääräistä statistiikkaa, mutta tämän parametrin selvittäminen ei ole hyökkääjällä suurikaan haaste. Käytännössä näitä takaovia ei saisi olla vaikka
ne olisivat piilotettu käyttäjältä koodin ohjelmallisella sekoituksella.
Jotkut verkkosovellukset sallivat käyttäjän lähettävän omia tiedostoja, esimerkiksi kuvia tai tyylitiedostoja, jotka muokkaavat sovelluksen ulkonäköä. Myös nämä pitäisi käsitellä virheellisen syötteen varalta, ettei verkkosivustolle saada näiden tiedostojen kautta
sisällytettyä hyökkääjän koodia.
3.2.2
Verkkopalvelut
Ajaxin hyödyntäminen verkkosovelluksessa avaa Ajaxin käyttämän verkkopalvelun hyökkäykselle. Melkein kaikki hyökkäykset mitä voidaan tehdä syötekentille, voidaan tehdä
myös verkkopalvelulle. Niitä vastaan on myös hyvin helppo hyökätä, koska sovelluksen
käyttämät palvelut ovat helposti löydettävissä ja ne todennäköisesti käsitellään palvelimella. Verkkopalvelu myös kasvattaa mahdollisia syötteiden lukumäärää, koska palvelun
metodilla voi olla useita parametreja ja jokaista vastaan voidaan hyökätä.
Ajaxin hyödyntäminen sovelluksessa myös paljastaa palvelimen toimintalogiikkaa käyttäjälle. Kun perinteisessä verkkosovelluksessa verkkopalvelusta paljastui esimerkiksi vain
dokumentin tallennusmetodi, niin Ajaxia hyödyntävä versio sovelluksesta paljastaa myös
oikeinkirjoituksen ja kieliopin tarkistavat metodit.
11
4.
TEKNIIKOITA TIETOTURVA-AUKKOJEN
VÄHENTÄMISEEN VERKKOSOVELLUKSISSA
Verkkosovelluksien tietoturva-aukkoja voidaan vähentää useilla tavoilla, jotka voidaan
jakaa JavaScript-kielen, selaimen ja verkkosovelluksen kehittäjän vastuulle.
4.1
JavaScriptin turvamekanismit
JavaScriptissä on omat turvamekanisminsa, joilla yritetään vähentää ilkeämielisen koodin
ajamista. Näitä mekanismeja kutsutaan Same-Origin Policyksi ja hiekkalaatikoksi.[4]
Same-Origin Policy rajoittaa JavaScript-koodin pääsyn vain saman verkko-osoitteen muuttujiin ja se myös rajoittaa koodia sen suhteen mihin verkko-osoitteisiin koodi voi ottaa yhteyttä. Samaksi verkko-osoitteeksi määritellään osoite, jolla on sama verkkotunnus, protokolla ja portti. Ei ole vaikutusta mistä osoitteesta JavaScript-koodin lataa, vaan ainoastaan
dokumentin lähteellä, johon JavaScript on sisällytetty. Esimerkiksi osoitteen google.com
JavaScript ei pääse käsiksi osoitteen ebay.com evästeisiin. Taulukossa 4.1 on listattu mille
sivuille osoitteen http://www.site.com/page.html JavaScriptillä on pääsy.
Taulukko 4.1: Saman verkko-osoitteen määrittäminen osoitteelle http://www.site.com/page.html
URL
http://www.site.com/page2.html
Pääsy Sallittu Syy
Kyllä
Sama
verkkotunnus,
protokolla ja portti
https://www.site.com/page.html
Ei
Eri protokolla
http://sub.site.com/page.html
Ei
Eri verkkotunnus
http://site.com/page.html
Ei
Eri verkkotunnus
http://www.site.com:8080/page.html Ei
Eri portti
JavaScriptin hiekkalaatikko rajoittaa mitä skripti voi tehdä kun se ajetaan. Ulkopuolisesta verkko-osoitteesta ladattu JavaScript ei tue luku- ja kirjoitusoperaatiota paikallisiin
tiedostoihin. Lisäksi hiekkalaatikko rajoittaa JavaScriptin tukemien ominaisuuksien toimintaa. Esimerkiksi asiakkaan ajama JavaScript voi käyttää HTTP-protokollaa vaihtaakseen dataa palvelimen kanssa tai vaikka ladata dataa FTP-palvelimelta. Mutta se ei voi
avata socket-yhteyttä ulkopuoliseen palvelimeen eikä palvelin voi ottaa yhteyttä asiakkaan ajamaan skriptiin. Seuraavaksi on listattu ominaisuuksia joita hiekkalaatikko voi
rajoittaa. Nämä rajoitukset tosin eroavat selainten välillä.
4. Tekniikoita tietoturva-aukkojen vähentämiseen verkkosovelluksissa
12
• JavaScript-koodi voi avata uusia selainikkunoita, mutta useimmat selaimet rajoittavat tätä popup-mainostajien varalta siten, että ikkuna avataan vain käyttäjän toimesta. Esimerkiksi kun käyttäjä klikkaa jotain komponenttia.
• JavaScript-koodi voi sulkea ikkunoita, jotka se on itse avannut, mutta se ei voi sulkea muita ikkunoita ilman käyttäjän varmistusta.
• JavaScript-koodi ei voi piilottaa linkkien kohteita asettamalla linkille status-tekstiä.
• Skripti ei voi avata ikkunaa, joka on liian pieni kooltaan tai pienentää avattua ikkunaa liian pieneksi. Skripti ei myöskään voi siirtää ikkunaa piiloon näytön ulkopuolelle tai luoda ikkunaa, joka on suurempi kuin näyttö. Tällä estetään skriptien
ajaminen ilman että käyttäjä huomaisi sitä.
4.2
Chromium-selaimen tietoturva-arkkitehtuuri
Chromium-selaimen arkkitehtuuri on rakennettu tietoturva huomioon ottaen.[5] Selaimessa jokainen välilehti on omassa prosessissa, joita hallinnoi selaimen kerneli. Jokaisella prosessilla on oma JavaScript-tulkki ja siten oman hiekkalaatikko, jolloin JavaScriptsovellukset on eriytetty toisistaan.
Jokaisella välilehtiprosessilla on renderöintimoottori, joka tulkkaa ja ajaa verkkosisältöä tarjoamalla oletustoiminnan. Renderöintimoottori sisältää suurimman osan selaimen
monimutkaisuudesta ja se kommunikoi suoraan verkon epäluotettavan sisällön kanssa.
Esimerkiksi renderöintimoottori jäsentää suurimman osan sisällöstä kuten HTML:n, kuvat ja JavaScriptin.
Selaimen kerneli hallinnoi renderöintimoottorit, ikkunoinnin, verkkosovelluksen pysyvän tilan, evästeet ja tallennetut salasanat. Se myös vuorovaikuttaa verkkoliikenteen
ja käyttöjärjestelmän natiivin ikkunointijärjestelmän välillä. Kerneli lisäksi hallinnoi tilatietoa oikeuksista, joita on kullekin renderöintimoottorille annettu. Tällä tilatiedolla kerneli toteuttaa turvallisen kommunikoinnin vaarannetun renderöintimoottorin ja käyttäjän
käyttöjärjestelmän välillä. Taulukossa 4.2 on taulukoitu kuinka Chromiumin tietoturvaarkkitehtuuri jakaa tehtävät renderöintimoottorien ja selaimen kernelin välillä.
4. Tekniikoita tietoturva-aukkojen vähentämiseen verkkosovelluksissa
13
Taulukko 4.2: Tehtävien jakaminen renderöintimoottorien ja selaimen kernelin välillä
Renderöintimoottori
Selaimen kerneli
HTML:n jäsentäminen
Evästetietokanta
CSS:n jäsentäminen
Historiatietokanta
Kuvien purkaminen
Salasanatietokanta
JavaScriptin tulkkaaminen Ikkunoiden hallinta
Säännölliset lausekkeet
Sijaintipalkki
Ulkoasu
Turvallisen selaamisen mustalista
DOM:n hallinta
Verkkopino
Renderöinti
SSL /TLS
SVG:n hallinta
Välimuistin hallinta
XML:n jäsentäminen
Tiedostonlatausjärjestelmä
XSLT muunnokset
Leikepöytä
Molemmat
URL:n jäsentäminen
Unicoden jäsentäminen
Tämä verkkosisällön eriyttäminen omiin renderöintimoottoreihin takaa, että jokainen
verkkosovellus voi toimia vain rajatulla määrällä toimintoja, eivätkä voi sekaantua muihin verkkosovelluksiin tai käyttöjärjestelmään. Arkkitehtuuri ei myöskään riko tukea jo
olemassa oleville verkkosovelluksille.
4.3
Turvallinen verkkosovellus
Täysin turvallinen verkkosovellus ei koskaan voi olla, mutta on olemassa tekniikoita joilla
hyökkääjälle ilmiselviä turva-aukkoja voi vähentää. Mm. datan validointi, johon hyökkääjä voi vaikuttaa, koodin ohjelmallinen sekoittaminen ja toimintalogiikan mahdollisimman
vähäinen siirto asiakkaalle.[1]
Perinteisessä verkkosovelluksessa datan validoinnilla tarkoitetaan käyttäjän syötteiden, evästeiden, tiedostojen ja istuntojen oikeellisuuden varmistamista. Ajax-sovelluksissa lisäksi pitää validoida Ajaxin paljastaman verkkopalvelun metodit ja niiden parametrit, varsinkin kun Ajaxin paljastamasta verkkopalvelusta on helppo selvittää parametrien
tyypit ja paluuarvot. Tämä helpottaa hyökkäämistä sillä poikkeavan datan generointi on
helpompaa, kun tiedetään minkälaista dataa palvelu odottaa.
Tekniikoita datan validointiin ovat mm. musta lista, valkoinen lista ja säännölliset
lausekkeet. Mustalla listalla tarkoitetaan listaa johon on tallennettu kaikki kielletyt syötteet. Esimerkiksi voidaan kieltää <script>-tagi XSS-hyökkäyksen varalta. Mutta mustan
listan ongelma on se, että siihen pitää tallentaa kaikki mahdolliset vaihtoehdot. Esimer-
4. Tekniikoita tietoturva-aukkojen vähentämiseen verkkosovelluksissa
14
kiksi <script>-tagi voidaan antaa myös muidoissa <SCRIPT> ja javascript::. Selain tulkitsee nämä kaikki samalla tavalla ja ajaa ne.
Valkoinen lista toimii päinvastaisesti kuin musta lista. Siinä listataan vain arvot, jotka ovat sallittuja. Esimerkiksi sallitaan sähköpostiosoitteeksi merkkijonot joissa on @merkki tekstin keskellä. Tämä tosin sallisi osoitteita joissa on ylimääräisiä @-merkkejä
tai viallisia verkko-osoitteita. Valkoisen listan ongelmana onkin suodattimen tarkan määrittelyn vaikeus. Suodattimen pitäisi päästää läpi kaikki validit osoitteet, mutta ei yhtään
epävalidia.
Säännöllisillä lausekkeilla voidaan tarkastaa monimutkaisia validiussääntöjä ohjelmallisesti. Esimerkiksi lausekkeella voidaan tarkastaa että syöte alkaa aakkosilla tai numeroilla, syötteen alkuosa saattaa sisältää viivoja tai pisteitä, alkuosan jälkeen pitää tulla
@-merkki, @-merkin jälkeen täytyy tulla vähintään yksi mutta enintään kolmen kirjain
ja numero osan joukko pisteillä erotettuna ja viimeisen osan täytyy päättyä pisteeseen.
Lopuksi syötteen pitää päättyä johonkin validiin korkean tason domainiin kuten .com tai
.org.
Näiden tekniikoiden yhdistämien tuo kaikkein tehokkaiman lopputuloksen: säännöllisillä lausekkeilla toteutettu valkoinen lista, jota täydennetään mustalla listalla sulkemaan
poikkeukset pois, joita valkoinen lista ei suodata.
Koodin ohjelmallinen sekoittaminen on tekniikka, jossa koodista poistetaan kommentit, muuttujat ja funktion nimet lyhennetään pariin merkkiin sekä koodilohkot uudelleenjärjestellään eval-funktion avulla. Esimerkiksi
a l e r t ( " H e l l o World ! " ) ;
sekoitettaisiin muotoon:
a
b
c
d
=
=
=
=
" o Wor " ;
" ale " ;
" ld ! \ " ) " ;
" r t ( \ " Hell " ;
eval ( b + d + a + c ) ;
Nämä koodin pätkät ovat toiminnaltaan samanlaisia mutta jälkimmäinen on paljon
hankalampi lukea. Sekoitustekniikoita on loputtomasti ja on olemassa kaupallisia ratkaisuja sekoittamisen automatisoimiseen, joka tekee luettavuudesta käytännössä mahdotonta. Mutta sekoittamiseen ei saa luottaa turvallisena ratkaisuna, koska jos koodi voidaan
ohjelmallisesti sekoittaa, se voidaan myös ohjelmallisesti selventää. Tosin sekoitettu koodi saattaa suojata hyökkääjiltä, joilla ei ole taitoja tai kärsivällisyyttä selventää koodia.[1]
4. Tekniikoita tietoturva-aukkojen vähentämiseen verkkosovelluksissa
15
Ajax-sovelluksissa toimintalogiikkaa siirretään asiakkalle, jotta saavutetaan pienempi
datan siirto palvelimen ja asiakkaan välille sekä vähemmän dataa palvelimen käsiteltäväksi pyyntöjen yhteydessä. Tietoturvan kannalta siirrettävä logiikka pitäisi minimoida, sillä toimintalogiikan paljastaminen helpottaa hyökkäystä. Esimerkiksi kauppasovellus siirtää hintojen yhteenlaskun asiakkaalle ja verkkopalvelu vastaanottaa lasketun yhteishinnan. Hyökkääjä voi muuttaa laskun lopputuloksen ja tilata tuotteet haluamallaan hinnalla. Vaikka toimintalogiikkaa on pakko siirtää asiakkaalle, se pitäisi rajoittaa ei-kriittisiin
toimintoihin kuten kartan liikutteluun tai muuhun tietosisällön esittämiseen.
16
5.
AJAX-SOVELLUSTEN TIETOTURVAN TESTAUS
Tietoturvan testaus on määrittelemättömän toiminnallisuuden etsimistä. Se että sovellus
toimii määrittelyn mukaan, ei takaa, että se voisi tehdä myös jotain muutakin. Ajaxsovellusten tietoturvan testaus tapahtuu hyvin samaan tapaan kuin hyökkäys. Koska pelkkä selain ei riitä tuottamaan kaikkia kyselyitä mitä hyökkääjät käyttävät, on testaukseen
käytettävä siihen suunniteltua ohjelmistoa. Näillä ohjelmistoilla voi generoida tuhansia
kyselyitä, joista saadaan tilastotietoa löydetyistä aukoista. Testaukseen on sekä avoimia
että kaupallisia ohjelmistoja.[1]
Testaus aloitetaan selvittämällä mitä verkkosovelluksesta pitää testata eli mitkä verkkosivut ja -palvelut ovat saavutettavissa. Tähän on kolme tekniikkaa: sivujen automaattinen haku linkkejä seuraamalla, välityspalvelimen kuunteleminen ja lähdekoodin analysointi.
Verkkosivujen automaattista tallennusta varten ohjelmalle annetaan aloitussivu, josta ohjelma alkaa tallentaa sivuja rekursiivisesti linkkejä seuraamalla. Tallentimen ollessa
täysin automaattinen, se ei vaadi interaktiota testaajalta, mutta se ei myöskään osaa reagoida esimerkiksi lomakkeisiin siten, että kentät saisivat järkeviä arvoja.
Välityspalvelinta kuuntelemalla tallennetaan sivuja sitä mukaa kuin testaaja niitä käyttää. Tämä vaatii testaajalta enemmän työtä, varsinkin jos sovellus on iso, kuin automaattinen tallennus. Mutta testaaja osaa täyttää lomakkeet järkevästi ja siten avata sivuja joihin
tallennin ei pääse. Mutta kumpikaan näistä tekniikoista ei löydä kaikkia sivuja: automaattisella tallentimella ei ole pääsyä sivuille, joille ei ole yhtään linkkiä ja ihmistestaajalta
saattaa jäädä sivuja testaamatta.
Lähdekoodin analysoinnilla löydetään kaikki sivut ja palvelut sekä mahdolliset takaovet, joita koodiin on kirjoitettu. Analysointityökalulle annetaan koko sovelluksen lähdekoodi ja tämä on tekniikan ainoa huono puoli. Jos verkkosovellus käyttää jotain toista
julkista verkkosovellusta, testaajalla ei todennäköisesti ole pääsyä tämän toisen sovelluksen lähdekoodiin.
Verkkosovelluksen tallennettuaan testaaja testaa sovellusta joko mustalaatikkotestauksella tai analysoimalla koodia lisää. Mustalaatikkotestauksessa tehdään samanlaisia kyselyitä sovellukselle kuin mitä käyttäjä voisi tehdä. Testaustyökalut lähettävät näitä kyselyitä ja analysoivat palvelimelta saatuja vastauksia tunnettuun odotettuun vastaukseen.
5. Ajax-sovellusten tietoturvan testaus
17
Analyysin perusteella kysely tulkitaan joko onnistuneeksi hyökkäykseksi tai turvalliseksi
kyselyksi.
Lähdekoodia analysoimmalla etsitään yleisesti tunnettuja tietoturva-aukkoja sekä analysoidaan sovelluksen suoritusta. Lähdekoodin analysoinnissa on heikkoina puolina Ajaxissa käytettäviä eri ohjelmointikielien sekamelska, joka saattaa johtaa siihen että kaikkea
koodia ei testata. Lisäksi automatisoidut analysaattorit ilmoittavat usein virheellisiä aukkoja. Mustalaatikkotestauksessa näitä ongelmia ei ole.
Testaukseen käytettäviä työkaluja ovat mm. ilmaiset Sprajax, Paros Proxy ja LAPSE (Lightweight Analysis for Program Security in Eclipse) sekä HP:n kaupallinen WebInspect.[1]
Esimerkkinä epäonnistuneesta testaukesta on kesällä 2006 paljastunut Yamanner-mato[1]. Tämä mato levisi Yahoo!:n sähköpostipalvelussa sähköpostiviestien välityksellä.
Kun käyttäjä lukee saamansa sähköpostin Yahoo!:n verkkopalvelussa, viestissä oleva JavaScript-koodi ajetaan mail.yahoo.com-kontekstissa. Jolloin kyseisellä koodilla on pääsy
Yahoo!:n evästeisiin ja se voi lähettää Ajax-pyyntöjä osoitteeseen mail.yahoo.com.
HTML-pohjaisissa sähköpostiviesteissä ei pitäisi olla JavaScript-koodia, sillä Yahoo!
riisuu viestistä JavaScriptin ennen kuin viesti näytetään käyttäjälle. Yahoo!:n verkkopalvelu mahdollistaa vain rajoitetun määrän HTML-tageja, jolloin sähköpostin lähettäminen,
jossa on koodin ajamisen mahdollistavia Script-tageja, ei onnistu ilman että verkkopalvelu riisuisi kyseiset tagit pois.
IMG-tagit sallittiin sekä viestien lähettämisessä että vastaanottamisessa, tarkoituksena
mahdollistaa kuvan liittäminen viestiin. Tagilla on ominaisuudet src ja onload. Src määrittelee liitettävän kuvan lähteen ja onload kuvan lataamisen jälkeen ajettavan koodin. Normaalisti Yahoo!:n suodattimet suodattavat ominaisuudet pois, jotka mahdollistavat koodin
ajamisen, kuten onload:n. Mato huijasi suodattimia seuraavalla tagilla:
<img s r c = ’ Yahoo_logo . g i f ’ t a r g e t = " " o n l o a d = " / / v i r u s k o o d i " >
Koska target-ominasuus ei ole sallittu img-tagissa, Yahoo!:n suodattimet suodattivat
ominaisuuden pois. Mutta viestiä ei uudelleen suodatettu ominaisuuksien riisumisen jälkeen jolloin tagista tuli seuraavanlainen:
<img s r c = ’ Yahoo_logo . g i f ’ o n l o a d = " / / v i r u s k o o d i " >
Koska mato käytti Yahoo!:n omaa logoa koodin ajamiseen, kuva oli aina ladattavissa
ja mato siten levisi käyttäjien osoitekirjoissa oleviin @yahoo.com osoitteisiin. Kun mato havaittiin, sen toiminnallisuus oli helposti pysäytettävissä poistamalla kyseinen kuva
verkkopalvelusta, kunnes suodattimissa ollut tietoturva-aukko oli paikattu.
18
6.
YHTEENVETO
Verkkosovelluksia tuottaessa on helppo luoda mahdollisia tietoturva-aukkoja hyökkääjille. Puuttelliset validoinnit, käyttäjän antaman syötteen näyttäminen sivulla sellaisenaan ja autentikaatioon sokeasti luottaminen ovat hyökkääjille helppoja kohteita. Ajaxteknologioiden käyttäminen kasvattaa verkkosovelluksen hyökkäyspinta-alaa entisestään
paljastaessaan sovelluksen käyttämän verkkopalvelun käyttäjälle ja siirtäessään toimintalogiikkaa asiakkaalle.
Turvallisen Ajax-sovelluksen lähtökohtana on, että käyttäjään ei voi luottaa. Kaikki
sisältö, johon käyttäjä voi vaikuttaa, pitää validoida ja tietoturvalle vaaralliset sisällöt hylätä kokonaan tai riisua niistä tietoturva-aukkoja hyödyntävät ominaisuudet pois. Vaikka
Ajax-teknologioiden käyttö vaatiikin toimintalogiikan paljastamisen käyttäjälle, sitä pitäisi paljastaa mahdollisimman vähän ja kriittiset toiminnallisuudet pitäisi pitää edelleen
palvelimella.
Ajax-sovelluksen tietoturvan testaus on tärkeää määrittelemättömän toiminnallisuuden
etsimistä, johon pitäisi panostaa käyttämällä testaajaa, joka ei ole kehittänyt kyseistä sovellusta. Testaus tapahtuu samaan tapaan kuin hyökkäyskin, mutta tuloksien perusteella
korjataan ongelmia hyväksikäytön sijaan.
19
LÄHTEET
[1] Billy Hoffman and Bryan Sullivan. Ajax Security. Addison-Wesley Professional,
2007.
[2] Chuan Yue and Haining Wang. Characterizing insecure javascript practices on the
web. In WWW ’09: Proceedings of the 18th international conference on World wide
web, pages 961–970, New York, NY, USA, 2009. ACM.
[3] Engin Kirda, Nenad Jovanovic, Christopher Kruegel, and Giovanni Vigna. Client-side
cross-site scripting protection. Computers & Security, 28(7):592 – 604, 2009.
[4] David Flanagan. JavaScript: The Definitive Guide. O’Reilly Media, Inc., 5th edition,
2006.
[5] Adam Barth, Collin Jackson, Charles Reis, and The Google Chrome Team. The
Security Architecture of the Chromium Browser. Technical report, Google Inc., 2008.
http://seclab.stanford.edu/websec/chromium/.