T Tekninen spesifikaatio

Transkriptio

1 T Tekninen spesifikaatio OtaShop2 Versio Päivämäärä Tekijä Kuvaus Tarkastettu Inkinen Dokumentti tarkastettu ja löydetyt virheet korjattu Ojanen Kannan kuvaus päivitetty Inkinen Oma tietoturvakappale, kuvausta admin-toiminnoista Inkinen Lisätty tietoturvaosio verkkomaksukappaleeseen Inkinen Dokumetti tarkastettu ja löydetyt epäkohdat korjattu Larmo Lisätty Käyttöliittymän kuvaus Ojanen Lisätty DAO:n kuvaus Inkinen Tarkennettu pakettien ja luokkien kuvauksia, käyttöliittymän kuvausta sekä otsikoita Kosunen Lisätty kuvaus language managerista Inkinen Muutoksia rakenteeseen ja otsikoihin. Uutta sisältöä pakettien kuvauksiin Ojanen Tietokannan kuvaus ja ER Inkinen Pohja luotu Sisältö 1. Johdanto 1.1 Asiakirjan tarkoitus 1.2 Määriteltävä tuote 2. Järjestelmä-alusta 2.1 Järjestelmän laitealusta 2.2 Tietokanta sekä laitealusta 3. Järjestelmän arkkitehtuuri 3.1 Järjestelmän yleiskuvaus 3.2 Suunnittelufilosofia 3.3 Java-paketit ja luokat 3.4 Tietokantakuvaus 3.5 Liitännät muihin järjestelmiin 4. Käyttöliittymä 4.1 JSP 5. Tekniset päätökset 5.1 Käytetyt tekniikat 5.2 Hylätyt tekniikat 6. Tietoturva 7. Lähteet 1. Johdanto 1.1 Asiakirjan tarkoitus Tämä dokumentti on OtaShop2-projektin tekninen spesifikaatio. Asiakirja on tarkoitettu järjestelmän tuleville ylläpitäjille ja siinä selvitetään järjestelmän tekninen toiminta, käytetyt teknologiat sekä ympäristö jossa järjestelmää käytetään. Asiakirja tulee olemaan tärkeä varsinkin projektin loppuvaiheessa jolloin valmis järjestelmä siirretään asiakkaan hallintaan. (1 of 15) [2/9/2004 1:19:16 AM]

2 1.2 Määriteltävä tuote Järjestelmä joka määritellään tässä dokumentissa on OtaShop2-verkkokauppa. OtaShop2 tulee Teknisen Korkeakoulun kirjaston (myöhemmin kirjasto) käyttöön. OtaShop2-kauppaa käytetään Teknillisen Korkeakoulun (TKK) laboratorioiden julkaisujen välittämiseen. Järjestelmä mahdollistaa maksujen, kuten tilauksesta ja postituksesta syntyvien kulujen perimisen ja maksamisen verkkopankin kautta. 2. Järjestelmä-alusta 2.1 Järjestelmän laitealusta Projektin vaatimukseksi on annettu että järjestelmä tulee toimia "kohtuuhintaisella laitteistolla". Koska järjestelmän vaatimat resurssit ovat riippuvaisia käytetystä sovelluspalvelimesta sekä kaupan asiakkaiden määrästä, ei laitteston enimmäishintaa ole määritelty tarkemmin. Kehitysvaiheessa järjestelmää käytetään laitteistolla ja ohjelmistoilla jotka on määritelty tarkemmin projektisuunnitelmassa. 2.2 Tietokanta ja laitealusta OtaShop2-järjestelmässä käytetään tietokantapalvelinta tilausten ja maksujen hallintaan. Kaikki pysyvä tieto tallennetaan tietokantaan. Pysyvää tietoa ovat julkaisujen tiedot, tuotteiden toimitukseen liittyvät tiedot sekä tarvittavat asiakastiedot. Julkaisutiedot löytyvät TKK:n kirjaston Tenttu-tietokannasta. Kirjasto päivittää uusimmat tiedot julkaisuista Tenttu-tietokantaan, ja OtaShop2:n julkaisutiedot replikoidaan kerran vuorokaudessa Tenttukannasta. OtaShop2:n tietokanta luodaan käyttäen standardi SQL:ää. Valmistajakohtaisia laajennuksia ei käytetä. Tällä tavalla voidaan varmistua siitä että otettaessa järjestelmää käyttöön ei olla riippuvasia yhden valmistajan ohjelmistosta tai sen versiosta. Järjestelmän toteutusvaiheessa tulemme käyttämään "Oracle 9i standard"-tietokantapalvelinta. 3. Järjestelmän arkkitehtuuri 3.1 Järjestelmän yleiskuvaus OtaShop2-verkkokauppa Järjestelmä pyritään toteuttamaan J2EE-standardin mukaan ja se on suunniteltu helposti laajennettavaksi. Toiminnallisuus eriytetään omiin paketteihin, ja jokaisella paketilla on julkinen rajapinta jonka kautta sitä käytetään. Modulaarinen rakenne helpottaa järjestelmän laajentamista sekä ylläpitämistä. Seuraavassa lyhyesti kunkin tällä hetkellä toteutetun paketin tarkoitus ja toiminta. Paketin nimi Lyhyt kuvaus paketin toiminnasta DAO Tietokantahakujen ja kannan ylläpitämiseen liittyvät toiminnot Cart Ostoskorin sekä HTTP-istunnon hallinta Order Tilausten sekä tuotteiden hallintaan liittyvät toiminnot Payment Maksamisen ja eri maksutapojen hallinta Language Sivulla näkyvien tekstien lokalisaatio Pakettien keskinäiset suhteet esitettän seuraavassa kuvassa. (2 of 15) [2/9/2004 1:19:16 AM]

3 3.1.2 OS2admin Järjestelmän ylläpito-osio, OS2admin, toteutetaan erillisenä J2EE-sovelluksena. OS2admin suoritetaan eri ympäristössä kuin itse verkkokauppa, mutta molemmat järjestelmät käyttävät samaa tietokantaa. 3.2 Suunnittelufilosofia (3 of 15) [2/9/2004 1:19:16 AM]

4 OtaShop2-järjestelmä on suunniteltu käyttäen tunnettuja suunnittelumalleja. Käytetyt mallit sekä niiden lähemmät kuvaukset löytyvät henkilökohtaisen tehtävän 'Design Patterns'-harjoituksesta. 3.3 Java-paketit ja luokat Seuraavassa on selvitetty tarkemmin kunkin paketin toiminta sekä niiden sisältämät luokat. Luokkien tarkka toteutus on luettavissa JavaDoc-dokumentaatiossa DAO DAO-paketti sisältää kaikki tietokantaan liittyvät toiminnot. Paketissa mallinnetaan myös kaupassa myytävät tuotteet, sekä niihin liittyvät tiedot. Paketti on suunniteltu siten että se mahdollistaisi uusien tuotetyyppien lisäämisen mahdollisimman helposti. Paketin mallina on käytetty sekä builder että factory -suunnittelumalleja, ja tämän avulla uusien tuotetyyppien lisääminen onnistuu ilman isompia muutoksia. DAO-paketin tarkempi kuvaus Paketissa on käytetty sekä builder että factory suunnittelumalleja. ItemBuilder luokka toimii sekä builderina että factorynä. DAO käyttää J2EE-ympäristön tarjoamaa yhteysvarantoa (connection pool) tietokantayhteyden luomiseen. Paketin toimintoja käytetään ShopDAO-rajapinnasta, josta saadaan halutunlainen DAOTypes-luokan tyyppien mukainen DAOinstanssi. ShopDAO:n finditems() -metodi hakee haluttujen tuotteiden tiedot tietokannasta. Sille annetaan argumenttina valmiit SQL where- ja order by -lauseet, jotka voidaan muodostaa automaattisesti ShopDAORequestParser-luokan avulla. ShopDAO käyttää abstraktista ItemBuilder-luokasta saatavaa tiettyä tuotetyyppiä rakentavaa instanssia myytävien tuotteiden mudostamiseksi tietokannan datasta. Item-rajapinnan toteuttaville tuoteluokille voidaan antaa ennaltamääräämätön määrä attribuutteja, joten rajapintaa voidaan käyttää täysin eri tyyppisten tuotteiden kehyksenä. (4 of 15) [2/9/2004 1:19:16 AM]

5 3.3.2 Cart Cart-paketti toimii asiakkaan ostoskorina verkkokaupassa asioinnin aikana. Halutut tuotteet voidaan tallettaa ostoskoriin, ja kun asiakas on valmis tekemään tilauksen, niin tiedot välitetään eteenpäin Order-paketille. Ostoskoriin voi vapaasti lisätä tuotteita sekä poistaa niitä istunnon aikana. Cart-paketin tarkempi kuvaus Cart-paketti koostuu vain yhdestä luokasta. ShoppingCart-luokka sisältää metodit joilla tuotteita voidaan lisätä, poistaa, muuttaa, tyhjentää koko kori ja kysyä korissa olevien tuotteiden määrää. Tuotteiden lisääminen tai poistaminen muuttaa automaattisesti tuotteiden lukumäärätiedon, eikä asiakkaan tai kutsuvan luokan tarvitse ottaa asiaan kantaa. Korissa voi olla samaa tuotetta useampi kuin yksi kappale, mutta tämän tiedon tallennus on toteutettu Item-rajapinnan kautta. Cart:n hallinnoima ostoskoritieto pysyy tallessa koko käyttäjän vierailun ajan, koska valinnat säilötään sovelluspalvelimen muistiin, käyttäjää varten luotuun istuntoon. Käytännössä jokaista verkkokaupassa vierailevaa käyttäjää varten luodaan HashMap-tyyppinen olio, johon käyttäjän toivomat Item-rajapinnan toteuttavat tuotteet tallennetaan Order Order-paketti on suunniteltu builder suunnittelumallia käyttäen. Order paketti pitää huolen asiakkaan ja tilauksen tietojen hallinasta. Order saa asiakastiedot käyttöliittymältä, josta tarkemmin kappaleessa Käyttöliittymä. Asiakastiedot tallennetaan istuntoon, josta ne välitetään eteenpäin payment-paketille. (5 of 15) [2/9/2004 1:19:16 AM]

6 Order-paketin tarkempi kuvaus Order-paketti koostuu abstraktista CustomerBuilder-luokasta sekä sen palauttamista asiakasta kuvaavista luokista. Paketin ulkopuoliset luokat käyttävät aina CustomerBuilder-luokkaa, joka automaattisesti asettaa asiakas-tyypin oikein. Kaikki asiakasta kuvaavat luokat totetuttavat Customer-rajapinnan. CustomerBuilder mahdollistaa asiakastietojen määrittelemisen eri tavoilla. OtaShop2-projektin ensimmäisessä vaiheessa asiakastietojen määritteleminen tehdään aina HTML-formin avulla, ja CustomerBuilder palauttaa FormCustomerBuilder-luokan. Pienillä muutoksilla CustomerBuilder-luokkaan on mahdollista toteuttaa asiakastietojen hakeminen esimerkiksi tietokannasta tai evästeestä (cookie) Payment Payment-paketti huolehtii verkkomaksu-tapahtumasta. Paketti on toteutettu siten että se mahdollistaa erillaiset maksutapahtumat. Tällä hetkellä hyväksytyt ja toteutetut maksutavat ovat verkkomaksu Nordean, Leonian ja Kultarahan verkkopankeissa. Myös varmistettu verkkomaksu Visalla (Verified by Visa) on tuettu. Edellisten lisäksi sallitaan vielä laskulla maksaminen. Luokissa on käytetty template method suunnittelumallia ja tämän johdosta uusien tapausten lisääminen on jatkossa helppoa. Paketti keskustelee Order-paketin kanssa, jolta se saa tarvittavat tiedot laskun summasta sekä maksutavasta. Näitä tietoja hyväksikäyttäen se ohjaa asiakkaan oikean pankin sivuille, josta maksu varsinaisesti suoritetaan. OtaShop2-järjestelmä siis ei suoraan käsittele asiakkaan maksutapahtumaa, vaan pankki hoitaa sen ja antaa siitä tiedon takaisin OtaShop2-järjestelmään. (6 of 15) [2/9/2004 1:19:16 AM]

7 Payment-luokka on paketissa abstrakti ja eri maksutavat perivät sen. Järjestelmän muut osat käyttävät tätä abstraktia luokkaa, eivätkä joudu käsittelemään eri maksutapoja. Tämä mahdollistaa uusien maksutapojen lisäämisen, ilman että järjestelmän muita osia tarvitse muuttaa. PaymentTypes-luokka määrittelee vakiot joilla eri maksutapoja voidaan kutsua. Maksutavan määrittää kaupan asiakas, joka asiakastietojen kyselyn yhteydessä voi valita maksutavan Language Language-paketti huolehtii verkkokaupan lokaalisaatiosta, eli monikielisyydestä. (7 of 15) [2/9/2004 1:19:16 AM]

8 Tarkempi kuvaus language-paketin luokista Language paketissa on ainoastaan yksi luokka. Se on järjestelmän apuluokka joka palauttaa halutuista teksteistä aina kielivalinnan mukaan oikean kieleisen version. LanguageManager luokka on toteutettu Singleton suunnittelumallilla. Eri kielet on toteutettu XML-tiedostona, josta aina haetaan oikea teksti, riippuen valitusta kielestä OS2admin Verkkokaupan ylläpito toteutaan omana erillisenä sovelluksenaan. OS2admin sisältää kaikki järjestelmän hallintaan liittyvät toiminnot, kuten tilausten ja käyttäjätunnusten hallinnan. Admin-paketti sisältää myös mahdollisuuden nähdä ja tulostaa eri osastoille tärkeitä näkymiä, esim kaikki laboratorion tilastot tai asiakastiedot julkaisujen välittämisen. Ylläpito ajetaan eri ymäritstössä kuin itse verkkokauppa, ja tämän ympäristön tulee mieluiten sijaita kokonaan erillisellä pavelimella. Jos sovellukset kuitenkin ajetaan samalla palvelimella, voidaan ne asentaa eri ympäristöihin ja erotellaan TCP-portin perusteella. Tämä mahdollistaa samalla sen että pääsyä admin-osioon voidaan rajoittaa sisäisesti ip-osoitteen mukaan, sekä ulkoisesti palomuurilla. Os2admin-järjestelmä käyttää samaa tietokantapalvelinta kuin itse kauppa. Itse kauppa ei käytä kaikkia tietokantataulujen kenttiä, vaan se lisää vain tilaukset järjestelmään asiakkaan tietojen kanssa. Os2admin-järjestelmä pysyy muokkaamaan myös muita tietoja, kuten tilausten tilaa (toimitettu/toimittamatta). Ylläpitojärjestelmä käyttää tietokantaa myös käyttäjäoikeuksien hallintaan. Järjestelmä mahdollistaa sekä kaupan että itse ylläpitojärjestelmän hallinan kokonaisuudessaan WWW-liittymän yli. Ylläpitojärjestelmän tietokantakuvaus on näytetty seuraavassa kappaleessa. 3.4 Tietokantakuvaus OtaShop2-tietokantaan on talletettu kaikki pysyvä tieto. Kannan sisältö muodostuu kahdesta pääasiallisesta osasta, kirjaston olemassaolevasta järjestelmästä siirrettävät tiedot (julkaisutiedot ja laboratorioiden tiedot) sekä OtaShop2:n omat tiedot. Julkaisutiedot saadaan TKK:n kirjaston Tenttu-tietokannasta, josta ne kerran vuorokaudessa replikoidaan OtaShop2:n tietokantapalvelimelle. Kirjaston omasta tietokannasta siirretään myös laboratorioiden vastuualuekoodit ja osastotiedot. OtaShop2-järjestelmän tuottamat tilaustiedot tallennetaan tietokantaan ja niiden tilaa ylläpidetään. Tietokanta sisältää myös kaupan muita tietoja, kuten ylläpitäjien käyttäjätietoja Tietokannan tarkka kuvaus OtaShop2-tietokannan rakenne on kuvattu seuraavissa ER-kaavioissa: Julkaisut: (8 of 15) [2/9/2004 1:19:16 AM]

9 publication-taulun kuvaus kokonaisuudessaan: Name Null? Type PUB_ID NOT NULL VARCHAR2(20) PRICE NOT NULL NUMBER(10) DOC_TYPE NOT NULL NUMBER(2) RESPONSIBLE_AUTHOR NOT NULL ALL_AUTHORS VARCHAR2(512) TITLE NOT NULL VARCHAR2(500) PUB_YEAR NOT NULL NUMBER(4) RESP_AREA_CODE NOT NULL VARCHAR2(10) DATE_SAVED NOT NULL VARCHAR2(10) DATE_ALTERED NOT NULL VARCHAR2(10) MAG_NAME VARCHAR2(300) MAG_VOLUME VARCHAR2(10) MAG_NUM VARCHAR2(10) SER_NUM VARCHAR2(10) SER_AUTHORS SER_TITLE VARCHAR2(512) EDITION PUB_PLACE PUBLISHER CONFERENCE VARCHAR2(200) PATENT PATENT_OWNER PATENT_INVENT PATENT_APPLICATION PAGE_NUMBERING KEYWORDS_ENGL VARCHAR2(300) FOREIGN_PUB VARCHAR2(4) (9 of 15) [2/9/2004 1:19:16 AM]

10 WEIGHT_FACTOR PROJECT SAVER_TRIP_ID CONF_AUTHORS CONF_TITLE ELECT_AVAIL AUTH_TITLE DESCRIPTION VARCHAR2(10) VARCHAR2(1024) Tilaukset: Ylläpito, käyttäjät: (10 of 15) [2/9/2004 1:19:16 AM]

11 3.5 Liitännät muihin järjestelmiin Tenttu-tietokanta OtaShop2-järjestelmä käyttää kirjaston Tenttu-tietokantaa julkaisutietojen ylläpitämiseen ja hallintaan. OtaShop2:n julkaisutietokanta replikoidaan sovituin väliajoin Tenttu-kannasta. Tietokannan replikointi on tarkemmin selvitetty kappaleessa "3.4.1 Tietokannan tarkka kuvaus" Verkkomaksu OtaShop2 ei itse hallitse verkkomaksutapahtumia, vaan itse maksu suoritetaan pankin omilla WWW-sivuilla. OtaShop2 välittää pankin maksujärjestelmään maksettavan summan, ja kun maksu on suoritettu saa järjestelmä tästä tiedon. Pankit ja luottokorttiyhtiöt joita tämä koskee on määritelty tarkemmin Payment java-paketin kuvauksessa. Tietoturva Verkkomaksu tapahtuu siten että OtaShop2-järjestelmä välittää pankille HTML-lomakkeen johon on tallennettu kaikki maksuun liittyvät tiedot. Tietojen tarkka esitystapa vaihtelee hieman pankista toiseen, mutta tiedot ovat pääosin samat. Tietoihin lisätään aina kaupan oma salainen avain jolloin pankki voi yksilöidä kaupan josta maksu on lähtöisin ja varmistetaan maksun aitous. Kaikista tiedoista muodostetaan merkkijono, josta lasketaan 128-bittinen MD5- tarkistussumma, joka varmistaa ettei asiakas tai muu taho pääse muuttamaan maksun tietoja kesken maksutapahtuman. Kaupan omaa tarkistusavainta käytetään vain tarkistussumman laskemisen yhteydessä, eikä sitä välitetä salaamattomana kaupanteon missään vaiheessa. Mikäli tämä avain tulee julki voi maksutapahtumia väärentää tai luoda tyhjästä joten avaimen salaisena pysyminen on ensiarvoisen tärkeää. Pankin palvelimelle annetaan tapahtuman yhteydessä myös paluuosoitteet johon pankin palvelin ohjaa käyttäjän maksun onnistuttua tai vaihtoehtoinen osoite mikäli maksu epäonnistuu. Paluu URL-osoitteeseen lisätään myös maksun parametrit, joten kaupassa voidaan helposti yksilöidä maksu paluuosoitteen ja parametrien perusteella. E- maksu antaa myös mahdollisuuden peruttaa jo tehtyjä maksuja, joten epäselvissä tilanteissa on mahdollista peruttaa maksu. Yhteys pankkiin muodostetaan käyttäen SSL-suojattua HTTPS-protokollaa. Protokollan avulla salataan kaikki liikenne joka liikkuu asiakkaan ja pankin välillä ja tekee salakuuntelun äärimmäisen vaikeaksi. SSL käyttää julkisen avaimen salausta jolla voidaan varmistua pankin "henkilöllisyydestä". Tämä suojaus auttaa nk. spoofing- sekä man-in-themiddle-hyökkäyksiä vastaan. Spoofing tarkoitta että joku kolmas taho väärentää pankin palvelimen, jota asiakas tietämättään käyttää oikean palvelimen sijaan. Man-in-the-middle-hyökkäys puolestaan tarkoittaa sitä että hyökkääjä tekee spoofing-hyökkäyksen sekä asiakkaan että pankin suuntaan, välittäen tiedon näiden välillä. Samalla hyökkääjä (11 of 15) [2/9/2004 1:19:16 AM]

12 pystyy muuttamaan kaikkea tietoa mitä yhteydessä välitetään, esim tilinumeroita ja salasanoja. Edellä esitetyt hyökkäykset ovat lähinnä kohdistettu asiakkaaseen. Koska kaupan avainta ei välitetä selväkielisenä edes pankille, mahdollinen hyökkääjä ei saa sitä haltuunsa. Avaimen arvaaminen tai laskeminen vaatisi MD5- protokollan murtamista, mikä on matemaattisesti erittäin vaikeaa. Mikäli MD5-protokollaa vastaan olisi olemassa tehokkaita hyökkäyksiä ei tätä maksutapaa enää voitaisi käyttää, sillä silloin olisi mahdollista väärentää maksuja. Verkkokauppa sallii myös laskulla tilaamisen ja tässä yhteydessä tilaus välitetään jo ennen laskun maksua. Tämän maksutavan mahdollinen väärinkäyttäminen on huomattavasti helpompaa kuin verkkomaksujen väärentäminen. Voidaan kuitenkin todeta, että koska julkaisuja välitetään omakustannushintaan, eivät käsiteltävät summat ole isoja, joten saavutettu turva on riittävä. 4. Käyttöliittymä Verkkokaupan käyttöliittymä ja ulkoasu on kuvattu tarkemmin erillisessä ulkoasudokumentissa. 4.1 JSP Verkkokaupan käyttö tulee tapahtumaan normaalia WWW-selainta käyttäen. Käyttöliittymä tullaan toteuttamaan siten, että asiakkailla ja ylläpitäjillä on erillaiset näkymät. Kaikki ylläpitoon liittyvät näkymät toiminnot tulevat olemaan käytettävissä selaimen kautta. Toteutus on tehty siten että itse kauppa- ja ylläpito-osiot on eriytetty eri palvelimille. Jos mahdollisuutta eri palvelinten käyttöön ei ole, voidaan tämä toteuttaa siten että ylläpito-järjestelmä ajetaan eri J2EE-palvelimen alla kuin mitä itse kauppa. Tällä tavalla saavutetaan seuraavat edut: Virhe kaupan koodissa ei vaaranna ylläpito-osiota Kauppa ja ylläpito pyörivät eri palvelimilla, joten pääsyä ylläpito-sivustoon voidaan rajata esim. Otaniemen sisään, tai vain erikseen sallituilta koneilta. Rajaaminen tulee tehdä sekä palvelimessa että käyttäen palomuuria. Kauppa sekä sen ylläpito voidaan sammuttaa ja/tai päivittää toisistaan riippumatta. Kaupan ulkoasu on tehty yhtenäiseksi OtaShop1-verkkokaupan kanssa. OtaShop1:n ulkoasu on suunniteltu yhdessä TKK:n viestintäkeskuksen kanssa joka on myös hyväksynyt ulkoasun. OtaShop1 on toinen verkkokauppa jonka TKK:n ATK-keskus on tilannut ja jossa myydään TKK:n logotuotteita, kuten pinssejä, t-paitoja ja mukeja. OtaShop1 toteutetaan PHP-tekniikkaa käyttäen. Koska ulkoasut ovat yhtenäiset voidaan kauppoja tarpeen vaatiessa käyttää myös rinnakkain. OtaShop2 on kuitenkin alusta lähtien suunniteltu siten että se on helposti laajennettavissa myös logotuotteiden myyntiin soveltuvaksi. Käyttöliittymä toteutetaan Java Server Pages-teknologiaa (JSP) käyttäen. JSP mahdollistaa dynaamisesti luotavien sivujen esittämisen ja antaa mahdollisuuden toteuttaa monimutkainen toiminnallisuus normaalina Javaohjelmakoodina. Kappaleessa 'Yleiskuvaus' on esitetty käyttöliittymän sekä Java-pakettien keskinäiset suhteet. 5. Tekniset päätökset 5.1 Käytetyt tekniikat Oracle 9i standard Järjestelmän kehitysvaiheessa tulemme projektissa käyttämään Oracle 9i standard-tietokantapalvelinta. Asiakas on toimittanut tämän ohjelmiston projektin käyttöön. Tietokannan rakenne ja toiminnot toteutetaan standardi SQL-kieltä käyttäen, joten tietokantapalvelin voidaan tarpeen vaatiessa vaihtaa toiseen, esimerkiksi käyttöönoton yhteydessä Apache WWW-palvelin Apache on tällä hetkellä käytössä TKK:n ATK-keskuksessa. Muita WWW-palvelimia ei käytetä. Tästä syystä myös OtaShop2:ssa tulee käyttää Apache WWW-palvelinta. Apache on tällä hetkellä suosituin WWW-palvelin markkinoilla. Apache on helposti laajennettavissa erillaisilla lisämoduleilla ja tarvitsemamme toiminnot löytyvät jo valmiiksi. Kaiken lisäksi Apache on ilmainen ja saatavilla hyväksymällä Apachen oma lisenssi joten se soveltuu erinomaisesti projektin käyttöön. (12 of 15) [2/9/2004 1:19:16 AM]

13 5.1.3 Apache Tomcat Tomcat on Apache-projektin Java-sovelluspalvelin. Projektissa käytetään Apache WWW-palvelinta joten ohjelmistot on rakennettu toimimaan keskenään saumattomasti. Tämän lisäksi Apache-projektissa on useita työkaluja jotka helpottavat projektin kääntämistä ja testaamista ja toimivat yhteen Tomcat-palvelimen kanssa. Projektissa käytetään Maven-käännösympäristöä, sekä JUnit-yksikkötestausjärjestelmää. 5.2 Hylätyt tekniikat PHP Projektin alussa järjestelmän toteutsvaihtoehdoissa annettiin asiakkaan puolesta joko PHP tai J2EE. OtaShop1, on toteutettu PHP:tä käyttäen. Neuvotteluissa asiakkaan kanssa totesimme kuitenkin että J2EE on sopivampi alusta OtaShop2:n toteutukseen sillä se mahdollistaa turvallisemman ja helpommin laajennettavan järjestelmän toteuttamisen. Tämän lisäksi kaikilla projektin jäsenillä on kokemusta Java-projekteista joten J2EE:n opetteluun ei kulu ylimääräistä aikaa. Vaatimusta tarkennettiin myöhemmin siten että J2EE on nyt vaatimus asiakkaan puolesta. 6. Tietoturva Tietoturvan kannalta järjestelmän tärkein osuus on ylläpito-sivusto. Ylläpito-järjestelmän kautta tulee olla pääsy kaikkiin kaupan toimintoihin ja tilauksiin. Täten myös sen suojaaminen on ensisijaisen tärkeää. Itse kauppa-osuus ei ole yhtä kriittinen, mutta samalla sen suojaaminen on vaikeaa, sillä kaupaan tule olla pääsy kaikkialta. Seuraavassa on selvitetty tarkemmin eri osioiden tietoturvaan liittyviä seikkoja. Tietoturvan suunnittelussa ja toteuttamisessa on pyritty ottamaan huomioon tunnettuja ja yleisiä heikkouksia, joita on esitetty OWASP:in ( The Open Web-Application Security Project ) Top 10-listassa, jossa on esitetty vaarallisimmat ja yleisimmät ongelmat verkkosovellusten tietoturvassa. Seuraavassa on listattu järjestyksessä kymmenen vaarallisinta virhettä OWASP Top 10-listan mukaan: 1. Unvalidated input Syötteen validointi, eli käyttäjän antamia syötteitä ei tarkisteta ennen käyttöä 2. Broken Access Control Salasanasuojatuissa sivustoissa on usein rajoitettu mitä osia kukin käyttäjä pääsee näkemään ja muuttamaan. Monesti oikeuksien tarkistus on toteutettu siten että ne pystyy kiertämään. 3. Broken Authentication and Session Management Yleensä käyttäjän kijautumisia ja oikeuksia seurataan käyttäen evästeitä. Mikäli evästeiden käyttö on huonosti toteutettu, voidaan niitä käyttää kiertämään valvonta. 4. Cross Site scripting Verkkosovelluksia voidaan käyttää välittämään hyökkäyksiä käyttäjän koneelle. 5. Buffer overflow Puskurin ylivuotoa voi johtaa siihen että hyökkääjä voi suorittaa haluamaansa koodia palvelimella. Yleensä tämä on läheisesti yhteydessä virheeseen Injection flaws Kun sovellukset välittävät parametreja voidaan sekaan laittaa käskyjä. Mikäli ei syötteitä ja parametreja tarkasteta ennen käyttöä voi tämä mahdollistaa koodin tai käskyjen ajamisen palvelimella. 7. Improper Error Handling Virhetapausten vääränlainen hallinta voi jopa johtaa siihen että hyökkääjä ottaa koneen haltuunsa. Yleensä virhetapauksia tai niiden antamaa informaatiota, kuten versionumeroita, voi käyttää hyväkseen muissa hyökkäyksissa. 8. Insecure storage Verkkosovellus tarvitsee yleensä tietokannan johon pysyvää tietoa tallennetaan. Mikäli tietokanta on huonosti suojattu, tai esim salasanat helposti saatavilla, tekee tämä palvelimen alttiiksi eri hyökkäyksille. 9. Denial of Service DoS tarkoittaa sitä että hyökkääjä käyttää palvelimen resursseja siinä määrin että normaali toiminta vaikeutuu tai jopa tulee mahdottomaksi. Huonosti ohjelmoidut turvamekanismit voivat helpottaa tällaisia hyökkäyksiä. 10. Insecure Configuration Management Vaikka verkkosovellus itsessään olisikin turvallinen niin se on silti alttiina hyökkäyksille, jos palvelin on suojaamaton. Tämän takia on tärkeää että palvelin on konfiguroitu oikein ja että käytetyt ohjelmistot ovat (13 of 15) [2/9/2004 1:19:16 AM]

14 päivitetty uusimmilla tietoturvapäivityksillä. 6.1 Verkkokaupan tietoturva Kauppa-osion tietoturvasta on keskusteltu myös kappaleessa Verkkomaksu, jossa on lähinnä keskitytty maksutapahtuman turvallisuuteen. Näitä asioita ei tulla toistamaan tässä, vaan ne sivutetaan muutamalla huomautuksella. Syötteen validointi/puskurin ylivuoto OWASP-listalla on listattu tärkeimmäksi yksittäiseksi viaksi parametrien validointi, tai sen puuttuminen. Epäsuorasti myös erillaiset puskurin ylivuotoon liittyvät hyökkäykset liittyvät tähän samaan ongelmaan. OtaShop2-verkkokaupassa käyttäjä pääsee syöttämään vapaamuotoisia tietoja teoksen hakemisen yhteydessä, sekä asiakastietojen syöttämisen yhteydessä. Nämä välitetään sitten eteenpäin tietokannalle, joten mahdollinen "SQL-injection", eli tietokantakäskyjen ajaminen paramterien seassa on mahdollinen. Tästä syystä kaikki parametrit tarkistetaan ja varmistetaan että ne ovat oikeata tyyppiä ja järkevissä rajoissa ennen kuin ne tallennetaan kantaan, tai niiden mukaan tehdään haku. Varmistamalla että arvot ovat halutun kaltaisia voidaan suojatua useimpia tämän tyyppisiä virheitä vastaan, kuten esim. puskurin ylivuotoa. Perinteisesti puskurin ylivuoto on ollut ongelma kielissä jossa ei ole puskurien tarkistusta, eli käytänössä C ja C++. Javassa tätä ongelmaa ei esiinny, joten tältä ei erikseen tarvitse suojautua. Kuitenkin jo edellä esitetyt tarkistukset auttavat samalla suojaamaan järjestelmää mahdollisilta ylivuodoilta. 6.2 Ylläpito-osuuden tietoturva Ylläpito-sivusto toteutetaan siten että tärkeisiin toimintoihin pääsy vaati salasanatarkistusta. Tärkeää on myös että järjestelmään toteutetaan mahdollisuus erillaisiin käyttäjäprofiileihin. Täten voidaan antaa kullekin laboratoriolle pääsy vain näiden omiin tietoihin, eikä muiden laboratorioiden tilauksia pääse näkemään tai muuttamaan. Ylläpito järjestelmä käyttää samaa tietokantaa kuin kauppa, mutta ei muuten ole suorassa yhteydessä kauppaan. Ylläpito voidaan siten tarpeen vaatiessa sijoittaa eri palvelimelle kuin itse kauppa. Kuten kappalleessa 4.1 jo mainittiin, niin tällä tavalla voidan varmistua siitä että mahdollinen turva-aukko kaupassa ei suoraan vaaranna ylläpidon toimintaa. Käyttäjien autentikointi Koska järjestelmään tulee runsaasti eri käyttäjiä on näiden hallinta tärkeässä roolissa. OtaShop2-järjestelmässä on käyttäjien autentikointi suoritettu J2EE-standardin mukaan. Käyttäjien autentikointi suoritetaan käyttäen tunnus/salasana-paria. Käyttäjien tunnukset ovat käytänössä julkista tietoa, sillä ne pyritään tekemään samaan muotoon kuin tunnukset muissa TKK:n järjestelmissä. Täten salasana on varsinainen autentikointiväline. Salasanat tulee tästä syystä tallentaa paikkaan jossa niihin ei ole pääsy kuin erikseen sallituilla tahoilla, kuten esim. järjestelmän ylläpitäjällä. Samalla vaatimuksena on että järjestelmää ajetaan ympäristössä jossa käyttäjien autentikointi suoritetaan SSL-suojattua yhteyttä käyttäen. Muussa tapauksessa salasanan voi salakuunnella joko palvelimen tai asiakkaan lähiverkosta. Salasanaa ei tulla tallentamaan selväkielisenä, sillä muuten kaikilla joilla on pääsy tiedostoon voivat esiintyä toisena henkilönä, käytteän tämän salasanaa ja tunnusta. Testivaiheessa salasanat ovat selväkielisinä, sillä tämä helpottaa toimintaa ongelmatilanteissa. Tuotantokäyttöön tulevassa järjestelmässä selväkielisen salasanan sijaan tallentaan salasanan ja salt-arvon hajautusfunktion arvo H( salt + pw ). Tällöin salasanan laskeminen hajautusarvosta on yhtä vaikeaa kuin hajautusfunktion kääntäminen, eli käytänössä mahdotonta. Salt-arvo on satunnainen luku 0:n ja MAX_SALT. Salt-arvon tulee olla julkinen, muuten ei salasanaa voida tarkistaa eikä siten käyttää autentikointiin. Saltin merkitys on siinä, että mikäli kaksi kahdella tunnuksella on sama salasana, niin ne tuottavat eri hash-arvot, mikäli käyttäjillä ei ole samaa salt-arvoa. Salt-arvon käyttäminen ei paranna yksittäisen salasanan turvallisuutta, mutta vaikeuttaa sanakirjahyökkäyksiä salasanatietokantoja vastaan. Hajautusfunktiona voidaan käyttää haluttua algoritmia, ja se voidaan tarpeen vaatiessa vaihtaa turvallisempaan, mikäli siitä versiosta löytyy vikoja. Tämä tosin vaati salasanojen uudelleen syöttämisen käyttäjien toimesta. Hajautusfunktiona OtaShop2-järjestelmässä tullaan käyttämään SHA1-algoritmia, joka tuottaa 160 bittisen hajautusarvon, mielivaltaisesta syötteestä. SHA1:stä vastaan ei ole tunnettuja hyökkäyksiä jotka olisivat tehookkaampia kuin nk. birthday attack. Tämä tarkoittaa että mikäli on annettu salasana x, tai sen hajautusarvo H(x), (14 of 15) [2/9/2004 1:19:16 AM]

15 niin saman sellaisen salasanan y löytäminen siten että H(x) == H(y) vaatii 2^160 operaatiota. Mikäli halutaan löytää kaksi satunnaista sanaa jotka tuottavat saman hash-arvon, vaaditaan 2^80 operaatiota. Vaadittavien resurssien vuoksi brute-force hyökkäykset hajautusfunktiota vastaan ovat lähinnä teoreettinen uhka. Tunnusten hallinta Järjestelmä mahdollistaa käyttäjien lisäämisen, mutta myös heidän poistamisen. Täten voidaan poistaa käyttäjät jotka eivät enää tarvitse tunnuksiaan. Samasta syystä käyttäjille luodaan henkilökohtaiset tunnukset, jolloin tämä henkilö voidaan poistaa ilman että tämä vaikuttaisi muiden tunnusten toimintaan. Eri tunnuksia ja niiden oikeuksia hallitaan roolien avulla. Jokainen tunnus voi saada yhden tai useamman roolin. Kulkuluvat annetaan rooleille, joten henkilö joka kuuluu tiettyyn rooliin saa kaikki sen oikeudet. Roolit on tehty hienojakoisiksi, jotta oikeuksien hallinta olisi mahdollisimman tarkkaa. Käyttäjien lisääminen ja tietojen hallinta tedään omalla admin-roolilla. Admin toimii samoin kuin muut roolit, mutta ylläpitäjällä on mahdollisuus lisätä uusia rooleja ja käyttäjiä, sekä muuttaa pääsyoikeuksia näille. Käyttäjät on myös ryhmitelty laboratorion mukaan, joten käyttäjillä ei ole mahdollisuutta päästä käsiksi muiden kuin oman laboratorion tilaustietokantaan. 7. Lähteet Asiakirjan nimi OtaShop2 vaatimusmäärittely OtaShop2 projektisuunnitelma Design Patterns OtaShop2 ulkoasudokumentti OWASP Top 10 of 2004 Lyhyt kuvaus asiakirjan sisällöstä OtaShop2-projektin vaatimusmäärittely dokumentti OtaShop2-projektin suunitelma Henkilökohtainen tehtävä: Design patterns, Matti Kosunen OtaShop2:n ulkoasun määrtelmä ja kuvaus OWASP Top 10 lista tietoturvaongelmista OWASP Guide to Building Secure Web Applications OWASP ohjeet verkkosovellusten kehittäjille Cryptography: Theory and Practice, 2nd Edition Douglas Stinson, Chapman & Hall/CRC Pankkien elektroonisen maksun dokumentit Nordean, Leonian ja OKO:n verkkomaksudokumentit (15 of 15) [2/9/2004 1:19:16 AM]