You are here: TUTWiki>Tietoturva/Tutkielmat>TyoLuettelo?>2008-11

Janne Husberg

"RESTful" web-palvelun tietoturvan toteutuminen

Johdanto

Web-palveluinten yleistyttyä monia vaivaa SOAP[1]-järjestelmien monimutkaisuus joka vaatii laajaa tuntemusta ja suuria ohjelmistokirjastoja. Useimmiten yhtiö haluaa vain yksinkertaisen rajapinnan jolla voidaan tarjota partnereille ohjelmoitavan tavan käyttää palvelua tai käyttäjilleen lisäarvoa mash-up:ien avulla.

Tästä syystä yhä useammat valitsevat Plain Old XML (POX) over HTTP ja REST -periaatteiden käytön järjestelmissään. Representational State Transfer (REST)[2] -periaatteilla suunniteltu web-palvelu ("REST-like web-palvelu", "RESTful web-palvelu") on rakennettu WWW:n periaatteiden mukaan jotta sen olisi helposti omaksuttavissa ja yhteensopiva tämän päivän Web X.0 maailmaan.

Tässä tutkielmassa tutkitaan REST-periaatteiden mukaisen web-palvelun turvallisen toteuttamisen tekniikoita. Esimerkkinä käytetään TVkaista Oy:n[3] web-palvelua - miten siinä tietoturvallisuus on suunniteltu, mitkä ongelmat tulivat eteen ja mitä ongelmia tulevaisuudessa voi odottaa.

REST-periaate

Useimmista arkkitehtuurityyleistä poiketen REST ei käytä suoria proseduurien etäkutsuja (Remote Procedure Call). Peruskonseptina on resurssi joka voidaan luoda, lukea, päivittää ja tuhota - muista datakeskeisistä mallista tutut CRUD (Create, Read, Update, Delete) -operaatiot.

On huomattu että nämät neljä operaatioita riittävät käytännössä kaikkiin tarvittaviin toimintoihin. Kunhan päästetään irti proseduurikutsujen ajatusmallista, kokonaisten ohjelmistojen rajapinnat voidaan suunnitella CRUD-mallilla ja samalla selkeytetään komponenttien-välisiä relaatioita, mikä hajautetuissa ohjelmistoissa on erittäin tervetullutta. Palveluiden välisiin toimintoihin tarvitaan ainoastaan tieto resurssin olinpaikasta, resurssin rakenne ja vakio operaatiojoukko jotka voidaan ajaa resurssia vastaan.

Kuten SOAP-, REST-periaattella toteutetun web-palvelun ei tarvitse käyttää HTTP-protokollaa, mutta siinä missä SOAP käyttää sitä pelkästään kokonaisen web-palvelun löytämiseen ja sen jälkeen kutsujen tunneloimiseen läpinäkymättömällä post operaatiolla - REST-periaatteilla voidaan hyödyntää kaikki protokollan ominaisuudet. Yksittäisen resurssin olinpaikkaan voidaan käyttää tuttua Uniform Resource Identifieriä (URI) ja resurssin tietorakenteen välittämiseen voidaan käyttää HTTP:n mediatyyppiä (myös tunnettu nimillä 'Content type', 'MIME type') joka suoraan kertoo tietorakenteen tyypin tai voidaan semanttisen verkon linkkien kautta tarjota XML-dokumenttien rakenteen määrittelevät DTD:t ja/tai XML Schemat. Mediatyyppeillä ja Accept-headerillä voidaan jopa tarjota useita erilaisia näkymiä resurssista; tavallinen HTML-sivu selaimelle ja XML-dokumentti toiselle palvelulle. Neljät vakio-operaatiot: luonti, luku, päivitys ja poisto, ovat suoraan muunnettavissa HTTP:n put, get, post ja delete operaatioiksi.

Esimerkki pseudokoodina:
User newUser = new User(...);
"web-service/users/{newUser.name}".put(newUser);

User me = "web-service/users/janne".get();

Message message = new Message("Hello, world!");
"{me.location}/blog".post(message);

"web-service/users/pnewman".delete();

HTTP-protokollan oikean käytön mukaan saadan näin melkein koko webin ominaisuudet. Kätkö- ja välityspalveluilla voidaan luoda palvelun tiedolle hajautettu saatavuusverkko - jopa oman verkon ulkopuolella. Semanttisella verkolla voidaan luoda resurssienvälisiä linkkejä useiden eri palveluiden välillä ilman erityistä sopimusta.

Erityisesti ylläpitäjille läpinäkyvät kutsut ja standardoidut virhekoodit tavallisen HTTP-kutsun headerissä, jotka L7 reitittimet ja tavalliset HTTP-välityspalvelimet voivat tarkastaa ilman koko viestin lukua, ovat avuksi verkon pääsynhallinnassa ja tiedonkulun tarkastelussa.

Erilaiset tietoturvatekniikat

Autentikaatio

HTTP-protokollaan sisäänrakennetut autentikaatiotavat, WWW-Authenticate ja Authorization headerit, tarjoavat kaksi eri tapaa autentikoida käyttäjätunnuksella ja salasanalla. Basic autentikaatiotapa lähettää tunnistustiedot vain Base64-enkoodattuna jolloin luottamuksellisuus on huono ellei salattua yhteyttä (katso Luottamuksellisuus, TLS), ja Digest autentikaatiotapa vaatii salasanan tallennusta palvelupuolella selvätekstina mikä ei aina ole suositeltavaa[4].

Näiden käyttö mahdollistaa web-palvelulle HTTP-protokollan tilattomuuden ja sen avulla helpon skaalautuvuuden, mutta tilallinen autentikaatio istunnoilla onnistuu myös joko tilapäisillä salasanoilla tai evästeellä. Silloin istunnosta voidaan luoda oma resurssi samoilla CRUD-operaatioilla, mutta jotta rajapinta olisi yhtenäinen resurssin tiedot pitää propagoida jokaiselle web-palvelua pyörittelevää ohjelmistopalvellimelle.

Hajautettu autentikaatio, jota useimmat Single Sign-On (SSO) järjestelmät käyttävät, on helppo toteuttaa HTTP:n 30x resurssienvälisiin uudelleenohjauksien avulla. Ongelmana on kuitenkin että uudelleenohjaus ei määrittele ajettavaa operaatiota, joten jotta uudelleenohjaukset toimisivat selaimilla halutulla tavalla, useimmmat HTTP-kirjastot lähettävät get:in suoraan uudelleenohjausta havaitessa.

Palveluiden väliseen autentikointiin käytetään yleensä kryptografisia sertifikaatteja. SSL/TLS-protokollaperheet sopivat tähän erinomaisesti jolloin voidaan tarkistaa sekä palvelun että käyttäjän identiteetti luotetun yhteyden muodostuksen yhteydessä.

Näiden palvelimen ja asiakaan välisten haaste-vaste -tekniikoiden huono puoli on kuitenkin, että kätköt eivät pysty turvallisesti pitämään autentikoitua kutsua tallessa, jolloin HTTP-protokollan mahdollistama skaalautuvuus huononee. Tulevaisuudessa tämä voisi muuttua, mutta siihen asti mahdollinen ratkaisu olisi pelkän tiedon enkryptaus jolloin autentikointi ja pääsynhallinta tapahtuisi kryptografisesti SOAP:in tietoturvallisuustekniikoiden tavalla. Tämä ei toimi ihmisten käyttämässä webissä, mutta ohjelmienväliseen kommunikointiin se soveltuu mainiosti.

Pyyntöjen läpinäkyvyyden avulla voidaan hajauttaa autentikaatio verkon reunaan, jolloin kätköjen pitäminen omassa verkossa on mahdollista ja tarjoaa hyvän skalaautuvuuden luku-operaatioille.

Istunnot

Koska SSL/TLS-protokollaperheiden molemminpuolista autentikointia ei yleensä voida käyttää, eikä ole suotavaa lähettää tunnistetietoja verkon yli toistuvasti, edes salattuna, on RESTin kanssa usein käytössä SOAP:in puolelta tuttu token, istuntotunniste. Istuntotunniste autentikoidaan kertaalleen, jonka jälkeen sitä voidaan käyttää autentikoinnin sijaan.

Pääsynhallinta

URI:n käyttö resurssin paikannustietona toimii erinomaisen hyvin tavallisten webin pääsylistojen kanssa. Yleisillä työkaluilla voidaan tarkistaa autentikoidun kutsujan pääsy resurssiin ja yleensäkin sen oikeudet eri operaatioihin lukemalla pelkän headerin. Protokollan läpinäkyvyyden takia tätä voidaan myös tehdä missä tahansa solmussa pakettien reitillä.

Koska REST käyttää HTTP:n metodeita, pääsynhallintaa voidaan URI-polun lisäksi toteuttaa myös näiden perusteella. Valitettavan monet "REST"-palvelut ovat kuitenkin "GET"-palveluita, jolloin tieto toiminnosta ei sisällykkään HTTP-tasolle, vaan löytyy pelkästään GET-viestin kyselystä.[5]

Luottamuksellisuus

HTTP-protokollan (oikeassa) käytössä luottamuksellisuus voi helposti rikkoutua välityspalvelimien ja kätköjen takia. Tämä huomiodaan yleensä käyttämällä Transport Layer Securityä, joka salaa koko yhteyden, mutta kutsujen läpinäkyvyys ja tiedon saatavuusverkko poistuvat.

Autentikaatiossa mainittu, SOAP web-palveluista tuttu, sovellustasoinen tiedon salaus voisi olla hyvä ratkaisu.

TVkaistan web-palvelu

TVkaistan suosituksen myötä halusimme keskittyä järjestelmän peruspalveluihin ja jättää käyttöliittymän ammattilaisille. Löysimme ohjelmistotalon joka täytti kriteerimme, mutta he käyttivät järjestelmissään toista ohjelmointikieltä - ja muutenkin olimme miettineet miten voisimme rajata rajapintaa järjestemäämme turvallisesti. Järjestelmämme oli suunniteltu luotetussa verkkossa toimivaksi ennen TVkaistan perustamista, joten sisäinen rajapinta antoi täydet oikeudet kaikkiin toimintoihin.

Sovimme että XML-pohjainen web-palvelu olisi helpoin ja nopein tapa muodostaa yhteys järjestelmien välillä ja REST-periaatte vaikutti lupaavalta.

Alustava suunnittelu

Alkuperäisen järjestelmän ollessa oliopohjainen RPC-rajapinta, käytimme palvelukeskeisen arkkitehtuurin periaatteita rajapintaa suunnittellessa, jotta web-palvelu olisi vain löysästi kytketty 'legacy' järjestelmään. Tällä tavalla saimme rajapinnan joka oli suunniteltu puhtaasti 'top-down'-menetelmällä ja mahdollisti selkeän pääsyhallinnan ulkopuoleltakin katsottuna. Uuden kumppanin lisäys toiseenlaisella sopimuksella olisi vain uuden pääsylistan (Access Control List, ACL) lisäys.

Autentikointiin oli suunniteltu pelkästään HTTP:n Basic autentikaatiomenetelmä, sillä yhteys kumppaniin olisi suunnitellessa aina luotettu. Autentikaatio oli alunperin suunniteltu pelkästään komponenttikohtaiseen pääsynhallintaan sellaisissa erikoistilanteissa, joisa ulkopuolinen taho saisi partnerin skriptikielellä toteutetussa järjestelmässä ajettua omia kutsuja.

Melko nopeasti löydettiin kuitenkin uusia kumppaneita jotka halusivat käyttää rajapintaa, eikä näiden verkkoihin pystytty luottamaan täydellisesti.

Ongelmat ja huolenaiheet

Yhden luotetun kumppanin pääsynhallinta toimi hyvin yksinkertaisella tavalla, jossa komponenttikohtaisesti pystyttiin rajaamaan niiden oikeudet pääsylistoilla. Uudet kumppanit olivat kuitenkin omissa verkoissaan ja yhteyksiin niihin ja tietovoihin niiden verkkojen sisällä ei pystytty luottaamaan täydellisesti.

Helpoin tapa säilyttää luotettavuus olisi käyttää sertifikaatteja sekä asiakas- että palvelinautentikaatiolla - yhteyskohtaisesti suojatun HTTP:n avulla (HTTPS) tai verkkojenvälisellä yhteydellä (VPN) jolloin viestin analysointi hajautetusti vielä onnistuisi.

Nämät muutokset olisivat kuitenkin vain hallinnollisia ja mahdollistaisivat web-palvelun käytön helposti ilman suojausta, vaikka tietoturvattomasti, julkisen verkon yli käyttäjien omissa 'mashup'-palveluissa - toisin kuin viestin kryptograafinen salaus, joka mahdollistaisi hajautetun saatavuuden kätköjen avulla.

Toinen huolenaihe, joka huomattiin testeissä, oli mahdollisuus palvelunestohyökkäyksiin joissakin toiminnoissa. Tämän ratkaisemiseen ovat ongelmallisia kuitenkin web-palvelun tilattomuus ja hajautus, jotka aiemmin mahdollistivat hyvän suorituskyvyn ja skaalautuvuuden, mutta estävät useiden yhtäaikaisen kutsujen laskennan. Tämän korjaamiseen tarvitaan joko web-palvelutarjoajien välillä yhteinen tilamuisti tai 'legacy'-järjestelmään uutta toimintoa, mikä ei välttämättä ole mahdollista.

Päätelmät

REST-periaatteilla tehdyllä web-palvelulla on useita ominaisuuksia jotka helpottavat kehittäjän ja palvelun käyttäjän työtä - luonteva rajapinta, läpinäkyvyys, tilaton hajautettavuus, yhteensopivuus olemassaolevien ylläpitotyökalujen kanssa - mutta HTTP:n tietoturvallisuustekniikat ovat liiankin yksinkertaiset ja rikkovat helposti hajautetun verkon parhaat osat.

HTTP-protokollan ongelmat ovat ihmisten webissä korjattu luomalla tilallisia palveluja evästeillä ja istunnoilla, mutta etsittäessä elegantimpia tekniikoita palvelunjenväliseen tietoturvaan kannattaa tarkistaa SOAP:in ja WS-perheen menetelmät. Julkisia HTTP-apeja luotaessa on huomattu, että REST-APi on yksinkertaisuutensa vuoksi SOAP-APIa huomattavasti suositumpi.

Kunnollisilla standardeilla ja yhteensopivuusprojekteilla WS-perheen tapaan REST-periaatteellisten web-palveluiden tulevaisuus näyttää kuitenkin kirkkaalta.

Lähteet

  • [1] SOAP v1.2 - W3C Recommendation [http://www.w3.org/TR/soap12-part1/] (viitattu 10.9.2008)
  • [2] Architectural Styles and the Design of Network-based Software Architectures - Representational State Transfer (REST) - Fielding, Roy Thomas. [http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm] (viitattu 10.9.2008)
  • [3] TVkaista NetPVR [http://tvkaista.fi] (viitattu 10.9.2008)
  • [4] RFC 2617: HTTP Authentication: Basic and Digest Access Authentication [http://tools.ietf.org/html/rfc2617] (viitattu 10.11.2008)
  • [5] Security and REST Web Services http://2007.xtech.org/public/asset/attachment/76 (viitattu 16.11.2009)
Print version |  PDF  | History: r6 < r5 < r4 < r3 | 
Topic revision: r6 - 31 Jan 2010 - 20:53:16 - MarkoHelenius
 

TUTWiki

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TUTWiki? Send feedback