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/.