Peruskäsitteet ja lähestymistavat¶

Selaimesta sovelluksiin (appification)¶

Viimeisten kymmenen vuoden aikana mobiililaitteiden ja internet-yhteyksien kasvu on muuttanut tapaa, jolla ohjelmistoja tuotetaan, levitetään ja kulutetaan. Myös ihmisten tapa käyttää tietokoneita ja ohjelmistoja on muuttunut. Tavalliset internet-selaimet ovat olleet hallitseva tapa käyttää verkkosisältöä mobiilia edeltäneellä aikakaudella, mutta sovelluksen käsite muutti merkittävästi tapaa, jolla käyttäjät pääsevät verkkosisältöön.

Appiﬁkaatio kuvaa ilmiötä, jossa verkon sisältöjen käyttö siirtyy pois verkkopohjaisesta alustasta sovelluksiin eli appeihin. Kun mobiililaitteista tuli maailmanlaajuisesti ensisijainen verkkokäyttöliittymä, appien määrä on kasvanut valtavasti. Appeja on kaikenlaisiin käyttötapauksiin ja sovellusalueisiin. Monet niistä näyttävät alkuperäisiltä työpöytä- tai mobiilisovelluksilta. Ne ovat kuitenkin usein (mobiili)verkkosovelluksia, jotka kommunikoivat taustapalvelujen kanssa ja ulkoistavat laskenta- ja tallennustehtävät asiakkaalle. Siirtyminen sovelluksiin vaikutti verkko- ja mobiilitietoturvaan ja loi lisää tietoturvahaasteita asiakaspuolelle. Nousu vaikutti myös kehittäjiin. Appeja edeltäneellä aikakaudella ohjelmistokehitystä hallitsivat enimmäkseen kokeneet kehittäjät. Laajemman työkalu- ja kehystuen ansiosta markkinoille pääsyn este on alhaisempi sovellusekosysteemeissä. Tämä houkuttelee kokemattomia kehittäjiä, ja sillä on kielteisiä seurauksia verkko- ja mobiiliturvallisuuteen yleisellä tasolla.

Ei-ammattilaisia sovellus- ja ohjelmistokehittäjiä kutsutaan kansalaiskehittäjiksi (citizen developer). Monilla heistä ei ole ohjelmistotekniikan koulutusta, mutta he käyttävät useita yksinkertaisia sovellusrajapintoja ja työkaluja sovellusten rakentamiseen eri alustoille. Helppokäyttöisten online-sovellusgeneraattoreiden (OAG) käyttöönotolla sovellusten kehittämiseen, jakeluun ja ylläpitoon on negatiivinen vaikutus sovellusten turvallisuuteen. Luodut sovellukset ovat monesti alttiita uudelleenkonfigurointi- ja injektiohyökkäyksille ja luottavat turvattomaan infrastruktuuriin.

WWW-teknologiat (webification)¶

Nykyaikaiset verkko- ja mobiilialustat synnyttivät toisenkin ilmiön, jota kutsutaan webifikaatioksi. Monet sovelluksista eivät ole natiiveja sovelluksia, jotka on kirjoitettu käännetyillä ohjelmointikielillä (Java tai Kotlin ja C/C++ (esim. Android-sovelluksille) tai Objective-C ja Swift (esim. iOS-sovelluksille)). Sen sijaan sovellukset pohjaavat verkkoteknologioihin, kuten palvelinpuolen Python, Ruby, Java tai JavaScript-skiriptit, ja asiakaspuolen JavaScript. Perinteisten selainpohjaisten verkkosovellusten lisäksi mobiiliverkkosovelluksia rakennetaan useammin näiden verkkotekniikoiden avulla. Erityisesti mobiiliverkkosovellukset käyttävät paljon JavaScriptiä. Tässä osassa käydään läpi näitä tekniikoita.

URL-osoitteet

URL-osoitteet (Uniform Resource Locator) ovat verkon ydinkonsepti. URL-osoite on muotoiltu merkkijono, joka osoittaa ja tunnistaa palvelimen resurssin. Osoiterivit nykyaikaisissa selaimissa käyttävät ja näyttävät URL-osoitteita. Absoluuttinen URL-merkkijono koostuu useista segmenteistä ja sisältää kaikki tarvittavat tiedot tiettyyn resurssiin pääsemiseksi. Syntaksi on: scheme://credentials@host:port/resourcepath?query_parameters#fragments. Jokaisella segmentillä on erityinen merkitys ja osa segmenteistä on valinnaisia.

scheme: ilmaisee protokollan, jota asiakkaan tulee käyttää resurssin hakemiseen, esim. http: ja https:
//: ilmaisee hierarkkisen URL-osoitteen rfc7540:n mukaan
credentials@: (valinnainen) voi sisältää käyttäjänimen ja salasanan, joita saatetaan tarvita resurssin noutamiseen
host: määrittää DNS-nimen (esim. tuni.fi), raa’an IPv4-osoitteen (esim. 127.0.0.1) tai IPv6-osoitteen (esim. [0:0:0:0:0:0:0:1]) osoittamaan resurssia isännöivän palvelimen sijainnin
:port: (valinnainen) kuvaa ei-oletusarvoisen verkkoportin yhteyden muodostamista varten, oletusportit ovat 80 (HTTP) ja 443 (HTTPS)
/resourcepath: resurssin osoite palvelimella, käyttää Unix-hakemistosemantiikkaa
?query_parameters: (valinnainen) välittää ei-hierarkkiset parametrit resurssille, esim. palvelinpuolen skriptin syötteen
#fragment: (valinnainen) antaa ohjeita selaimelle, sisältää HTML-ankkurielementit dokumenttien sisäistä navigointia varten

HTTP

HTTP (Hypertext Transfer Protocol) on verkossa laajimmin käytetty mekanismi dokumenttien vaihtamiseen palvelimien ja asiakkaiden välillä. Vaikka HTTP:tä käytetään enimmäkseen HTML-dokumenttien siirtämiseen, sitä voidaan käyttää mihin tahansa dataan. Laajimmin tuettu protokollaversio on HTTP/1.1, uusin on HTTP/2.0. HTTP on tekstipohjainen protokolla, joka käyttää TCP/IP:tä. HTTP-asiakas aloittaa istunnon lähettämällä HTTP-pyynnön (request) HTTP-palvelimelle. Palvelin palauttaa HTTP-vastauksen (response), jossa on pyydetty tiedosto.

HTTP-pyynnön ensimmäinen rivi sisältää HTTP-versiotiedot (esim. HTTP/1.1). Jäljellä oleva pyynnön otsikko (header) koostuu nollasta tai useammasta nimi:arvo -parista. Parit erotetaan uudella rivillä. Yleiset pyyntöotsikot ovat User-Agent – nämä sisältävät selaintiedot, Host – tämä on URL-isäntänimi, Accept – joka sisältää kaikki tuetut dokumenttityypit, Content-Length – koko pyynnön pituus ja Cookie – eli eväste, näistä puhutaan tarkemmin myöhemmin. Pyynnön otsikko päättyy yhdelle tyhjälle riville. HTTP-asiakkaat voivat välittää mitä tahansa sisältöä palvelimelle. Vaikka sisältö voi olla mitä tahansa, se on yleensä HTML-sisältöä, esim. web-sivulla olleen lomakkeen tiedot. HTTP-palvelin vastaa pyyntöön vastausotsikolla, jota seuraa pyydetty sisältö. Vastauksen otsikko sisältää tuetun protokollaversion, numeerisen tilakoodin ja valinnaisen, ihmisen luettavan tilaviestin. Tilaa käytetään ilmoittamaan pyynnön onnistumisesta (esim. status 200), virhetiloista (esim. status 404 tai 500) tai muista poikkeuksellisista tapahtumista. Vastausten otsikot voivat sisältää myös evästeotsikoita. Vastauksen lisäotsikkorivit ovat valinnaisia. Otsikko päättyy yhdelle tyhjälle riville, jota seuraa pyydetyn resurssin todellinen sisältö. Kuten pyynnön sisältö, sisältö voi olla mitä tahansa tyyppiä, mutta se on usein HTML-dokumentti. Vaikka evästeet eivät olleet osa alkuperäistä HTTP RFC:tä, nykyisin ne ovat yksi tärkeimmistä protokollalaajennuksista. Evästeiden avulla palvelimet voivat tallentaa useita nimi=arvo pareja asiakkaan tallennustilaan. Palvelimet voivat asettaa evästeitä lähettämällä Set-Cookie: name=value vastausotsikon ja käyttää niitä lukemalla asiakkaan Cookie: name=value pyyntöotsikon. Evästeet ovat suosittu tapa ylläpitää istuntoja asiakkaiden ja palvelimien välillä ja autentikoida käyttäjiä.

HTTP on pyyntö-vastauspohjainen ja sopii hyvin yksisuuntaiseen tiedonsiirtoon. Parempaa latenssia ja tehokkaampaa kaistanleveyden käyttöä varten tarvitaan kuitenkin kaksisuuntaisia verkkoyhteyksiä. Kaksisuuntaiset yhteydet sallivat asiakkaiden noutaa tietoja palvelimelta, mutta myös palvelin voi siirtää tietoja asiakkaalle milloin tahansa. WebSocket-protokolla tarjoaa tähän mekanismin HTTP:n päälle. WebSocket-yhteydet alkavat tavallisella HTTP-pyynnöllä, joka sisältää Upgrade: WebSocket-otsikon. Kun WebSocket-kättely (handshake) on valmis, molemmat osapuolet voivat lähettää tietoja milloin tahansa ilman uutta kättelyä.

HTML

HTML (Hypertext Markup Language) on laajimmin käytetty tapa tuottaa ja käyttää verkkodokumentteja. Uusin versio on HTML5. HTML-syntaksi on melko yksinkertainen: hierarkkinen puurakenne tageista, name=value tag -parametreista ja tekstisolmuista muodostavat HTML-dokumentin. Document Object Model (DOM) määrittelee HTML-dokumentin loogisen rakenteen ja säätelee, miten sitä käytetään ja miten sitä käsitellään. Kilpailevat selainvalmistajat esittelivät kuitenkin kaikenlaisia mukautettuja ominaisuuksia ja muokkasivat HTML-kieltä toiveidensa mukaan. Monet erilaiset selaintoteutukset johtivat siihen, että vain pieni osa internetin verkkosivustoista noudattaa HTML-koodia standardin mukaan. Tästä syystä HTML-jäsennyksen toteutukset ja virheistä toipuminen vaihtelevat suuresti eri selaimissa.

HTML-syntaksissa on joitain rajoituksia sille, mitä parametriarvo tai tekstisolmu voi sisältää. Jotkut merkit (esim. kulmasulut, lainausmerkit ja et-merkit) muodostavat HTML-merkinnän lohkot. Aina kun niitä käytetään johonkin muuhun tarkoitukseen, esim. tekstin osana, ne on eroteltava (escape). Ei-toivottujen sivuvaikutusten välttämiseksi HTML:ssä on entity encoding scheme, joka muuntaa symbolit html-kokonaisuuksiksi. Kuitenkin, jos varattujen merkkien koodausta ei käytetä oikein, seurauksena voi olla vakavia tietoturvaongelmia, esim. Cross-Site Scripting -hyökkäys.

CSS: CSS (Cascading Style Sheets) on mekanismi HTML-dokumenttien ulkoasun muokkaamiseen. CSS:n ensisijaisena tavoitteena oli tarjota suoraviivainen ja yksinkertainen tekstipohjainen kuvauskieli, joka korvaisi monet toimittajakohtaiset moniin epäjohdonmukaisuuksiin johtaneet HTML-tunnisteparametrit. Kuitenkin eri selaimet toteuttavat myös erilaista CSS-jäsennyskäyttäytymistä. CSS:n avulla HTML-tageja voidaan skaalata, sijoittaa tai koristella ilman alkuperäisen HTML:n merkintärajoituksia. Kuten HTML-tagien arvot, CSS:n sisällä olevat arvot voivat olla käyttäjän ohjattavissa tai ne voivat tulla ulkopuolelta, mikä tekee CSS:stä ratkaisevan tärkeän verkkoturvallisuuden kannalta.

JavaScript

JavaScript on yksinkertainen mutta tehokas olio-ohjelmointikieli verkkokäyttöön. Se toimii sekä asiakaspuolella verkkoselaimissa että palvelinpuolella osana verkkosovelluksia. Kieli on tarkoitettu tulkittavaksi suorituksen aikana, ja siinä on C-vaikutteinen syntaksi. JavaScript tukee luokatonta objektimallia, tarjoaa automaattisen roskienkeruun ja heikon ja dynaamisen tyypityksen. Tässä keskitytään asiakaspuolen JavaScriptiin verkkoselaimissa. Jokaiselle selaimen HTML-dokumentille on annettu JavaScript-suorituskonteksti. Kaikki dokumenttikontekstin skriptit jakavat saman hiekkalaatikon (sandbox). Kontekstien välistä skripti-viestintää tuetaan selainkohtaisten APIen kautta. Suorituskontekstit ovat yleensä tiukasti eristettyjä toisistaan. Kaikki kontekstin JavaScript-lohkot suoritetaan yksitellen ja hyvin määritellyssä järjestyksessä. Skriptien käsittelyssä on kolme vaihetta:

Jäsentäminen (parsing) validoi skriptin syntaksin ja kääntää sen binäärimuotoon. Koodilla ei ole vaikutusta ennen kuin jäsentäminen on valmis. Syntaksivirheitä sisältävät lohkot ohitetaan ja seuraava lohko jäsennetään.
Function Resolution rekisteröi kaikki nimetyt globaalit funktiot, jotka jäsentäjä löysi lohkosta. Kaikki rekisteröidyt funktiot ovat seuraavan koodin käytettävissä.
Suoritus (execution) suorittaa kaikki koodikäskyt funktioiden ulkopuolella. Poikkeukset voivat kuitenkin johtaa suoritusvirheisiin.

Vaikka JavaScript on erittäin tehokas ja tyylikäs skriptikieli, se on aiheuttanut uusia haasteita ja turvallisuusongelmia, esim. Cross-Site Scripting -haavoittuvuuksia.

WebAssembly: WebAssembly (Wasm) on tehokas ja nopea web-ympäristöä varten tarkoitettu ohjelmointikieli. Useimmat nykyaikaiset selainvalmistajat tukevat sitä. WebAssembly suorittaa koodia natiivinopeudella asiakaskoneissa. WebAssemblylla kirjoitettu koodi on muistiturvallista ja hyötyy kaikista verkkosivustoon liitetyn tavallisen koodin turvaominaisuuksista. WebAssembly-koodi toimii hiekkalaatikossa, noudattaa same origin -politiikkaa (same origin policy, SOP) ja on rajoitettu verkkosivuston lupien tarjoamiin resursseihin. Lisäksi WebAssembly-koodi voi käyttää JavaScript-koodia, joka on käynnissä samassa alkuperäsäiliössä (origin container). WebAssemblyn toiminnallisuus on myös samasta alkuperästä peräisin olevan JavaScript-koodin käytössä.

WebViews: WebViews mahdollistaa verkkosisällön helpon integroinnin mobiilisovelluksiin. Kehittäjät voivat integroida sovelluksia HTML:n ja JavaScriptin kanssa ja hyötyä siirrettävyyden eduista. WebViews toimii tavallisten mobiilisovellusten yhteydessä ja mahdollistaa monipuolisen kaksisuuntaisen vuorovaikutuksen verkkosisällön kanssa. Mobiilisovellukset voivat kutsua JavaScriptiä verkkosisällöstä ja seurata verkkosisällön tapahtumia. Lisäksi JavaScript APIt voivat sallia WebView-sovellusten vuorovaikutuksen sisältöön ja sensoreihin WebView-kontekstin ulkopuolella. Verkkosisällön vuorovaikutus natiivin sovellussisällön kanssa aiheuttaa uusia turvallisuusongelmia ja mahdollistaa sekä sovelluksesta verkkoon että verkosta sovellukseen -hyökkäykset. Sovelluksesta verkkoon -hyökkäykset antavat haitallisten sovellusten injektoida JavaScriptiä isännöityihin WebVieweihin paljastaakseen arkaluontoisia tietoja tai huijatakseen WebViews navigoimaan ja esittämään käyttäjille epäluotettavia ja mahdollisesti haitallisia verkkosivustoja. Verkosta sovellukseen -hyökkäykset injektoivat sovellukseen epäluotettavaa verkkosisältöä ja laajentavat sovelluksen JavaScript-siltaa taustalla olevaan isäntäsovellukseen. Verkosta sovellukseen -hyökkäyksen tavoitteena on oikeuksien eskaloituminen sen isännöintisovelluksen prosessin tasolle.

Sovelluskaupat¶

Sovelluskaupat ovat keskitettyjä digitaalisia jakelualustoja, jotka vastaavat ohjelmistojen hallinnasta ja jakelusta monissa WWW- ja mobiiliekosysteemeissä. Esimerkkejä ovat Chrome-verkkokauppa Chrome-selaimen laajennuksille, Applen AppStore iOS-sovelluksille ja Google Play Android-sovelluksille. Käyttäjät voivat selata, ladata ja arvioida mobiilisovelluksia tai selaimen laajennuksia. Kehittäjät voivat ladata ohjelmistonsa sovelluskauppoihin, jotka hoitavat kaikki ohjelmistojakelun haasteet, kuten tallennustilan, kaistanleveyden ja osan mainonnasta ja myynnistä. Ennen julkaisua useimmissa sovelluskaupoissa on käytössä sovellusten hyväksymisprosessi luotettavuuden testaamiseksi, myymäläkäytäntöjen noudattamiseksi ja tietoturvaongelmien seulomiseksi.

Jos ekosysteemissä on sovelluskauppa, suurin osa sen ohjelmistoista jaetaan kauppojen kautta. Vain harvat käyttäjät lataavat ohjelmistoja sivustoilta (eli asentavat ohjelmistoja muista lähteistä kuin kaupasta). Sovelluskaupan tarjoajalla on mahdollisuus hallita, mitkä sovellukset ovat saatavilla eli on mahdollista kieltää tiettyjä sovelluksia. Tästä voi seurata sensuurisyytöksiä, mutta tietoturvaongelmien seulontatekniikoiden käyttöönotto on auttanut vähentämään merkittävästi sovelluskauppojen haittaohjelmien määrää ja vähentämään myös sellaisten sovellusten määrää, jotka kärsivät turvallisuus-APIen väärinkäytöstä johtuvista haavoittuvuuksista. Käytetyt seulontatekniikat sisältävät staattisen ja dynaamisen analyysin, jota sovelletaan sovellusbinääreihin ja käynnissä oleviin sovelluksiin. Lisäksi sovelluskaupat edellyttävät sovellusten allekirjoittamista kehittäjän tai sovelluskaupan avaimilla. Androidissa sovellusten allekirjoittaminen ei perustu samoihin julkisen avaimen infrastruktuureihin, joita käytetään verkossa. Sen sijaan kehittäjiä kehotetaan käyttämään itse allekirjoitettuja varmenteita ja heidän on allekirjoitettava sovelluspäivitykset samalla avaimella haitallisten päivitysten estämiseksi. iOS-laitteissa sovelluksen allekirjoitus edellyttää Applen allekirjoitusta ja allekirjoittamattomia sovelluksia ei voi asentaa iOS-laitteisiin. Sovelluskaupat tarjoavat kehittäjille ja käyttäjille keskitetyn pääsyn ohjelmistojen julkaisemiseen, jakeluun ja lataamiseen, ja lisäksi ne antavat käyttäjille myös mahdollisuuden arvioida julkaistuja sovelluksia. Käyttäjien arvioiden tarkoituksena on auttaa muita käyttäjiä tekemään tietoisempia latauspäätöksiä, mutta niillä on myös suora yhteys sovellusten tietoturvaan. On havaittu, että tietoturvaan ja yksityisyyteen liittyvät käyttäjien arvostelut vaikuttavat sovelluksen tuleviin tietoturvaan liittyviin päivityksiin.

Mobiili- ja selainalustojen hiekkalaatikot¶

Nykyaikaiset mobiili- ja selainalustat käyttävät erilaisia hiekkalaatikkotekniikoita sovellusten ja verkkosivustojen sekä niiden sisällön eristämiseen toisistaan. Tällä pyritään myös suojaamaan alustaa haitallisilta sovelluksilta ja sivustoilta. Tärkeimmät verkkoselaimet (esim. Google Chrome) ja mobiilialustat (esim. Android) toteuttavat eristyksen käyttöjärjestelmän prosessitasolla. Jokainen sovellus tai verkkosivusto toimii omassa prosessissaan. Oletusarvoisesti eristetyt prosessit eivät voi vuorovaikuttaa toistensa kanssa eivätkä ne voi jakaa resursseja. Selaimissa sivuston eristäminen toimii toisena puolustuslinjana ja jatkeena same origin -politiikalle.

Sovellusten eristäminen: Nykyaikaiset mobiilialustat tarjoavat jokaiselle sovellukselle oman erillisessä prosessissa toimivan hiekkalaatikon ja oman tallennustilan tiedostojärjestelmässä. Mobiilialustat hyödyntävät taustalla olevan käyttöjärjestelmän prosessien turvamekanismeja sovellusten resurssien tunnistamiseen ja eristämiseen. Esimerkiksi Androidin sovellusten hiekkalaatikot on määritetty kernel-tasolla. Tietoturvaa toteutetaan käyttöjärjestelmän vakiotoimintojen avulla, esim. käyttäjä- ja ryhmätunnuksilla sekä turvakonteksteilla. Oletusarvoisesti hiekkalaatikko estää sovelluksia pääsemästä käsiksi toisiin sovelluksiin ja sallii vain rajoitetun pääsyn käyttöjärjestelmän resursseihin. Suojattujen sovellusten ja käyttöjärjestelmän resurssien käyttäminen edellyttää sovellusten välistä viestintää valvottujen rajapintojen kautta.

Sisällön eristäminen

Sisällön eristäminen on yksi tärkeimmistä turvallisuuden takaajista nykyaikaisissa selaimissa. Pääideana on eristää dokumentit lähteensä (origin) perusteella, jotta ne eivät voi vaikuttaa toisiinsa.

Same origin -politiikka (SOP) otettiin käyttöön vuonna 1995. Se vaikuttaa JavaScriptiin ja sen vuorovaikutukseen dokumentin DOM:n, verkkopyyntöjen ja paikallisen tallennustilan (esim. evästeiden) kanssa. SOP:n ydinajatus on, että kaksi erillistä JavaScript-suorituskontekstia saavat käsitellä dokumentin DOM:ia vain, jos document host täsmää tarkasti protokollaan, DNS-nimeen ja porttiin. Protokolla, DNS-nimi ja portti muodostavat tripletin, jota kutsutaan lähteeksi (origin). Cross-origin manipulointipyyntöjä ei sallita. SOP:n suuri puute on, että se luottaa DNS:ään IP-osoitteiden sijaan. Hyökkääjät, jotka voivat muuttaa DNS-merkinnän IP-osoitetta, voivat kiertää SOP-turvatakuun.

Koska same origin -politiikkaa toteuttava koodi sisältää toisinaan tietoturvavirheitä, nykyaikaiset selaimet käyttävät toistakin puolustuslinjaa: verkkosivustot renderöidään omissa prosesseissaan, jotka toimivat hiekkalaatikossa. Hiekkalaatikoitujen sivustojen tarkoituksena on estää hyökkäyksiä, esim. sivustojen välisten evästeiden ja tallennettujen salasanojen varastaminen.

Kolmas tapa verkkosovellusten turvallisuuden parantamiseksi on Content Security Policy (CSP) -mekanismi. CSP on ensisijaisesti tarkoitettu estämään koodin injektointihyökkäykset (esim. cross-site scripting, XSS), jotka käyttävät hyväkseen selaimien luottamusta verkkopalvelimen lähettämään sisältöön. Liika luottamus mahdollistaa haitallisten komentosarjojen suorittamisen asiakkaiden selaimissa. CSP:n avulla web-kehittäjät ja palvelinoperaattorit voivat rajoittaa lähteiden määrää, joita selain pitää luotettavina sisältölähteinä (tähän sisältyy myös suoritettava koodi ja mediatiedostot). CSP:tä voidaan käyttää siten, että palvelimet voivat globaalisti estää koodin suorittamisen asiakkaalla. Ottaakseen CSP:n käyttöön kehittäjät tai operaattorit voivat joko määrittää verkkopalvelimen lähettämään Content-Security-Policy HTTP-vastausotsikon tai lisätä HTML <meta>-tagin verkkosivulle. Yhteensopivat selaimet suorittavat sitten vain koodia tai lataavat mediatiedostoja luotetuista lähteistä.

Lupadialogiin perustuva pääsynvalvonta (syventävä)¶

Nykyaikaisten mobiili- ja verkkoalustojen lupajärjestelmät turvaavat käyttäjien yksityisyyttä kontrolloimalla resursseihin pääsyä. Perinteisten tietokonejärjestelmien pääsynvalvontaa on kuvattu aiemmassa luvussa ja niissä pääsynvalvonta edellyttää tietoturvaperiaatteiden ja suojattujen resurssien tarkkaa määrittelyä. Lisäksi perinteinen pääsynvalvonta vaatii luotetun mekanismin pääsypyyntöjen arvioimiseksi (viitemonitori) ja suojauskäytännöt, jotka määrittelevät asianmukaisen toimintatavan kaikille pääsypyynnöille. Suojauskäytäntöjen perusteella viitemonitori päättää, myöntääkö se pääsyn vai estääkö sen.

Nykyaikaiset mobiili- ja verkkoalustat poikkeavat monin tavoin perinteisistä tietokonejärjestelmistä pääsynvalvonnan osalta. Alla on lueteltu eroja:

Turvatoimijat: Perinteiset tietokonejärjestelmät ovat pääasiassa monen käyttäjän järjestelmiä, joita ihmiset käyttävät, ja joissa prosessit tekevät asioita ihmisten puolesta. Nykyaikaiset mobiili- ja verkkoympäristöt laajentavat tavanomaisia monikäyttäjäjärjestelmiä huomioimaan myös kaikki mukana olevat kehittäjät, joiden sovelluksia on asennettuna järjestelmän turvallisuustehtäviin turvatoimijoina (security pricipals).

Viitemonitori

Tyypillisesti perinteiset tietokonejärjestelmät toteuttavat pääsynhallinnan osana käyttöjärjestelmää. Käyttäjätason prosessit voivat laajentaa käyttöjärjestelmän toimivuutta ja toteuttaa omia pääsynvalvontamekanismejaan.

Myös nykyaikaiset mobiili- ja verkkoalustat rakentuvat käyttöjärjestelmän matalan tason pääsynvalvontamekanismien päälle. Lisäksi sovelluskehykset, joiden päälle sovelluksia kehitetään ja otetaan käyttöön, tarjoavat laajennettuja rajapintoja. Nykyaikaiset verkko- ja mobiilialustat käyttävät Inter-Process Communication (IPC) -tekniikkaa sovellusten sekä sovellusten ja käyttöjärjestelmän välisten etuoikeuksien erottamiseen ja lokerointiin sen sijaan, että ne sallisivat suoran pääsyn resursseihin. Kutsuprosessien pääsynvalvontamekanismeja käytetään IPC-liitäntöjen suojaamiseen.

Turvapolitiikka

Perinteisissä tietokonejärjestelmissä prosessilla voi olla erilaisia käyttöoikeustasoja. Se voi toimia pääkäyttäjänä, järjestelmäpalveluna, käyttäjätason oikeuksilla tai vierasoikeuksilla. Kaikilla prosesseilla, joilla on sama käyttöoikeustaso, on samat oikeudet ja ne voivat käyttää samoja resursseja.

Nykyaikaiset mobiili- ja verkkoympäristöt tekevät selvän eron järjestelmän ja kolmansien osapuolien sovellusten välillä: pääsy turvallisuuden ja yksityisyyden kannalta kriittisiin resursseihin myönnetään vain tietyille prosesseille, ja kolmansien osapuolien sovelluksilla ei ole oletusarvoisesti pääsyä kriittisiin resursseihin. Jos tällaista käyttöoikeutta tarvitaan, sovelluskehittäjien on pyydettävä käyttöoikeuksia joukosta, joka on yleisesti saatavilla kaikille kolmansien osapuolien sovelluksille. Useimmat käyttöoikeudet antavat kehittäjille mahdollisuuden käyttää määritettyjä järjestelmäprosesseja ”sijaisina”, kun tarvitaan pääsy suojattuun arkaluonteiseen resurssiin. Nämä järjestelmäprosessit myös toimivat viitemonitorina ja toimeenpanevat pääsynvalvontakäytäntöjä.

Lupadialogi

Mobiili- ja verkkoympäristöissä alustat erottavat eri käyttöoikeustasot. Yleistä on kaksi lupatasoa (esim. Androidissa): normaalit (esim. pääsy Internetiin) ja vaaralliset käyttöoikeudet (esim. pääsy kameraan tai mikrofoniin). Vaikka sovelluskehittäjien on pyydettävä sekä normaaleja että vaarallisia käyttöoikeuksia saadakseen sovelluksilleen pääsyn vastaaviin resursseihin, tasot vaihtelevat sovellusten käyttäjille. Normaalit käyttöoikeudet myönnetään ilman sovelluksen käyttäjän toimia. Mutta kun sovellukset pyytävät vaarallisia käyttöoikeuksia, taustalla oleva mobiili- tai verkkoalusta esittää käyttäjille lupadialogin. Aiemmin Android-versiot näyttivät käyttäjille luettelon kaikista sovelluksen pyytämistä käyttöoikeuksista asennuksen yhteydessä, mutta nykyaikaiset mobiilialustat ja selaimet esittävät lupadialogit ajon aikana. Lupadialogi näytetään yleensä ensimmäisen kerran, kun sovellus pyytää pääsyä vastaavaan resurssiin. Käyttäjät voivat sitten joko myöntää tai estää sovelluksen pääsyn resurssiin. Nykyaikaiset lupapohjaiset pääsynvalvontajärjestelmät mahdollistavat suuremman joustavuuden ja hallinnan sekä kehittäjille että käyttäjille.

Tästä seuraa kuitenkin vastuuta kehittäjille ja vaatimuksia käyttäjälle. Vaikka teoriassa suurempi joustavuus ja hallinta on mahdollista, tutkimuksissa on huomattu, että Android-sovelluskehittäjät saattavat pyytää sovelluksilleen enemmän käyttöoikeuksia kuin tarvitaan. Tällöin rikotaan vähimpien oikeuksien periaatetta. Käyttäjien osalta tutkimuksissa on huomattu, että käyttäjät eivät välttämättä ymmärrä oikein, mitä lupia heiltä pyydetään ja mikä luvan antamisen merkitys on. Usein lupadialogi ohitetaan lukematta ja lupa vain annetaan nopeasti, jotta sovellusta pääsee käyttämään.

Julkisen avaimen infrastruuktuuri WWW:ssä ja HTTPS¶

Julkisen avaimen infrastruuktuuri (public key infrastructure, PKI) ja HTTPS-protokolla ovat keskeisiä nykyaikaisissa mobiili- ja WWW-alustoilla, jotka molemmat perustuvat asiakas-palvelin-arkkitehtuureihin. WWW-alustoilla WWW-palvelimet ja sovellukset vaihtavat tietoja selaimien kanssa. Mobiilialustoilla sovellukset vaihtavat tietoja taustapalvelinten kanssa. Molemmissa tapauksissa HTTPS:ää tulee käyttää suojattuun verkkoyhteyteen asiakkaiden ja palvelimien välillä. Turvallisten verkkoyhteyksien luomiseen käytetään julkisen avaimen infrastruktuuria. WWW-PKI- ja X.509-varmenteiden avulla asiakkaat ja palvelimet voivat autentikoida toisensa ja vaihtaa salausavaimet salattua tiedonsiirtoa varten.

HTTPS on laajimmin käytetty suojattu verkkoprotokolla verkossa ja mobiilissa. Siinä HTTP kulkee TLS-protokollan päällä ja samalla varmistetaan palvelimen autentikointi ja siirrettävien tietojen eheys ja luottamuksellisuus. Vaikka HTTPS tarjoaa palvelimien ja asiakkaiden keskinäisen autentikoinnin X.509-sertifikaattien perusteella, pääasiassa sitä käytetään palvelimen autentikointiin. HTTPS suojaa HTTP-liikennettä TLS:n avulla salakuuntelulta ja peukaloimiselta estämällä välimieshyökkäykset. Koska HTTPS kapseloi HTTP-liikenteen, se suojaa URL-osoitteita, HTTP-otsikkotietoja ja evästeitä, ja HTTP-sisältöä hyökkääjiltä. Se ei kuitenkaan salaa asiakkaiden ja palvelimien IP-osoitteita ja porttinumeroita. Vaikka HTTPS piilottaa asiakkaiden ja palvelimien vaihtaman tiedon, salakuuntelijat voivat kuitenkin saada tietoja käyttäjien vierailemien verkkosivustojen ylätason verkkotunnuksista ja tunnistaa taustapalvelimet, joiden kanssa mobiilisovellukset kommunikoivat.

Sekä verkkoselaimet että mobiilisovellukset autentikoivat HTTPS-palvelimet toteamalla varmentajan (certificate authority, CA) allekirjoittaman X.509-sertifikaatin validiksi ja verifioimalla sen avulla palvelimen allekirjoituksen. Selainten ja mobiilisovellusten mukana tulee luettelo esiasennetuista varmentajista tai ne luottavat käyttöjärjestelmään asennettuun CA-listaan. Nykyaikaisissa selaimissa ja nykyaikaisissa mobiiliympäristöissä esiasennettu varmentajaluettelo sisältää tyypillisesti satoja varmentajia. Jotta HTTPS-palvelinvarmenne olisi luotettava, sen on oltava yhden esiasennetun CA:n allekirjoittama.

Selaimet näyttävät käyttäjille varoituksen, kun palvelimen varmennetta ei voida validoida. Varoitukset on tarkoitettu varoittamaan man-in-the-middle-hyökkäyksen mahdollisuudesta. Yleisiä syitä varoituksiin ovat kuitenkin virheelliset varmenteet, eri hostnimelle myönnetyt varmenteet, asiakkaan ja palvelimen väliset verkkovirheet, ja asiakkaan virheet, kuten väärin konfiguroitu aika. Useimmissa tapauksissa käyttäjät voivat napsauttaa varoitusta ja edetä verkkosivustolla, vaikka palvelimen varmennetta ei voitaisi validoida.

Selaimet käyttävät värejä osoitepalkissa näyttääkseen verkkosivuston suojaustiedot. Esimerkiksi seuraavissa tilanteissa tiedot näytetään suojaamattomina:

HTTP:n kautta ladatut verkkosivustot
HTTPS-verkkosivustot, jotka lataavat osan sisällöstään (esim. CSS-tai JavaScript-tiedostot) HTTP-yhteyden kautta
Lataaminen sivustolta, joka käyttää virheellistä varmennetta, mutta joiden kohdalla käyttäjä päätti edetä siitä huolimatta

HTTPS-sivustot, joilla on voimassa oleva varmenne, näytetään suojattuina. Mobiilisovellusten ja ei-selainsovellusten käyttäjät eivät voi kuitenkaan näin helposti tarkistaa, käyttääkö sovellus suojattua HTTPS-protokollaa voimassa olevalla varmenteella, koska selainten kaltaisia visuaalisia turvailmaisimia ei ole saatavilla. Sen sijaan käyttäjien on luotettava sovelluskehittäjiin siinä että HTTPS-yhteys on toteutettu oikein.

Autentikointi¶

Autentikointi verkossa ja mobiilialustoilla on tärkeä suojausmekanismi, jonka avulla käyttäjät voivat vahvistaa identiteettinsä verkkosovelluksissa, mobiililaitteissa tai mobiilisovelluksissa. Autentikointi kulkee käsi kädessä valtuutuksen kanssa, joka kuvaa resurssien käyttöoikeuksien määrittelyä. Määritettyjä käyttöoikeuksia käytetään myöhemmin myöntämään tai kieltämään pääsy resursseihin todennetuille käyttäjille. Autentikoinnista yleisesti puhutaan enemmän toisessa luvussa. Tässä luvussa keskitytään WWW- ja mobiiliautentikoinnin erityispiirteisiin.

HTTP-autentikointi

HTTP:n yhteydessä autentikaatiolla tarkoitetaan yleensä asiakkaan identiteetin verifiointia palvelimelle, esim. vaatimalla asiakaalta pääsypyynnön yhteydessä joitain ennalta määritettyjä salaisuuksia (esim. käyttäjätunnus ja salasana). Tässä käsitellään kahta verkossa yleisesti käytettyä autentikointimenetelmää: perus HTTP-autentikointia ja useammin käytettyä lomakepohjaista HTTP-autentikointia.

Perus HTTP-autentikointia käytetään resurssien pääsynvalvontaan. Se ei riipu istuntotunnisteista tai evästetiedoista. Perus HTTP-autentikointijärjestelmä ei myöskään vaadi erillisten kirjautumissivujen määrittämistä, koska kaikki yleisimmät selaimet tarjoavat integroidun kirjautumislomakkeen. Palvelin voi käynnistää autentikoinnin lähettämällä vastausotsikon, joka sisältää “HTTP 401 Unauthorised” -tilakoodin ja “WWW-Authenticate: Basic” -kentän. Asiakkaan tähän lomakkeeseen syöttämät tunnistetiedot yhdistetään “:” (“Käyttäjänimi:Salasana”), Base64-koodattu siirtoa varten (“VXNlcm5hbWU6UGFzc3dvcmQK”) ja lisätään valtuutusotsikkona seuraavaan pyyntöön (“Authorization: Basic VXNlcm5hbQZK3”v6cmUGFzcW3). Esimerkki palvelimen ja asiakkaan autentikoinnista on esitetty kuvassa yllä. Perus HTTP-autentikointi ei ole turvallinen, koska valtuustiedot lähetetään yksinkertaisen Base64-koodauksen jälkeen, joka on triviaali selvittää. Ilman lisäturvaa kirjautumistiedot välitetään pelkkänä tekstinä verkon yli, joten hyökkääjät voivat helposti varastaa kirjautumistiedot. Siksi perus HTTP-autentikointia ei tule käyttää ilman lisäturvaa (esim. HTTPS), joka varmistaa luottamuksellisuuden ja eheyden.

Lomakepohjainen HTTP-autentikointi, jossa verkkosivustot käyttävät lomaketta kirjautumistietojen keräämiseen, on yleinen autentikointitapa nykyaikaisissa verkko- ja mobiilisovelluksissa. Tässä mallissa todentamattomalle asiakkaalle, joka yrittää käyttää rajoitettua sisältöä, näytetään HTML-pohjainen verkkolomake, joka pyytää hänen kirjautumistietojaan. Asiakas lähettää tunnistetiedot palvelimelle (esim. POST-pyynnöllä). Palvelin vahvistaa lomakkeen tiedot ja autentikoi asiakkaan onnistuneen vahvistuksen yhteydessä. Perus HTTP-autentikoinnin tapaan lomakepohjainen autentikointi paljastaa käyttäjän tiedot pelkkänä tekstinä, ellei se ole HTTPS suojattu.

Mobiililaitteiden autentikointi

Mobiililaitteet käyttävät erilaisia autentikointimekanismeja laitteiden lukituksen avaamiseen, pääsyn myöntämiseen käyttäjille, ja tietojen suojaamiseen laittomalta käytöltä. Yleisimmät mobiililaitteiden autentikointimekanismit ovat salasanat, PIN-koodit, kuviot ja biometriset ominaisuudet.

Käyttäjät voivat käyttää yleisiä aakkosnumeerisia salasanoja, mukaan lukien erikoismerkkejä. Koska mobiililaitteelle autentikointi on kuitenkin usein toistuvaa, monet käyttäjät pyrkivät avaamaan mobiililaitteensa lukituksen käyttämällä esim. numeerisia PIN-koodeja. Android-laitteet tukevat myös lukituksen avauskuvioita, joilla salasanan tai PIN-koodin sijaan käyttäjät voivat valita avauskuvion 3x3-ruudukosta. Myös biometriikka, kuten kuten sormenjälki- ja kasvojentunnistusta, on vaihtoehto. Nämä autentikointitavat perustuvat laitteiston suojausprimitiiveihin, esim. ARM:n TrustZone.

Evästeet¶

Web-palvelimet liittävät tilatietoja asiakkaisiin käyttämällä HTTP-evästeitä (cookies). Asiakas tallentaa evästetiedot (esim. verkkokaupan ostoskoriin lisätyt tuotteet). Evästeiden avulla asiakkaat ja palvelimet sisällyttävät istuntotunnisteensa HTTP-pyyntövastaukseen, jolloin toistuvaa autentikointia ei tarvita. Istuntoevästeet vanhenevat, kun istunto suljetaan (esim. kun asiakas sulkee selaimen), mutta pysyvät evästeet vanhenevat vasta tietyn ajan kuluttua.

Evästepohjainen autentikointi antaa asiakkaille mahdollisuuden luoda istuntoja uudelleen, kun asiakas lähettää pyynnön evästeineen palvelimelle. Evästepohjainen istunnonhallinta on altis istuntotunnisteiden kaappaukselle. Valideja istuntoevästeitä lähettävä hyökkääjä voi muodostaa yhteyden palvelimelle autentikoidun uhrin oikeuksilla. Palveluntarjoajat voivat käyttää evästeitä myös käyttäjien seuraamiseen useissa istunnoissa. Tämä yleensä vaarantaa käyttäjien yksityisyyden.

Salasanat ja vaihtoehdot¶

Salasanat ovat laajimmin käytetty mekanismi, jolla käyttäjät voivat autentikoitua verkkosivustoille ja mobiilisovelluksiin ja suojata arkaluontoisia tietojaan. Salasanojen suosio autentikointikäytössä perustuu alhaisiin kustannuksiin, käyttöönotettavuuteen, mukavuuteen ja käytettävyyteen. Salasanojen turvallisuus kuitenkin kärsii, koska niitä käytetään lähes kaikkialla. Tämä johtaa käytettävyysongelmiin käyttäjien näkökulmasta. Koska ihmisillä on usein vaikeuksia muistaa monia erilaisia monimutkaisia salasanoja, he valitsevat usein heikkoja salasanoja ja käyttävät samaa salasanaa uudelleen useissa palveluissa. Hyökkääjät voivat helposti arvata heikot salasanat. Uudelleen käytetyt salasanat voimistavat kaikkien salasanahyökkäysten vakavuutta, koska yksi tili murtamalla saadaan pääsy monelle muulle, jossa on käytössä sama salasana. Salasanaohjeet suosittelivat aiemmin usein monimutkaisten salasanojen käyttöä, mutta monimutkaisten salasanojen vaatiminen saattaa itse asiassa heikentää salasanan turvallisuutta. Salasanoissa pituus on monimutkaisuuutta tärkeämpää ja esimerkiksi salalauseita käyttämällä voidaan myös helpottaa muistettavuutta.

Online-palveluntarjoajat käyttävät erilaisia vastatoimia heikkojen salasanojen ja salasanojen uudelleenkäytön aiheuttamien turvallisuusongelmien ratkaisemiseksi:

Salasanapolitiikat: Salasanapolitiikat ovat sääntöjoukkoja, jotka kannustavat käyttäjiä valitsemaan vahvempia salasanoja. Jotkut salasanapolitiikat käsittelevät myös muistettavuusongelmaa. Vahvempien salasanojen tukemiseksi useimmat politiikat koskevat salasanan pituutta ja merkkivaatimuksia, mustia listoja huonoista ja kielletyistä salasanoista, ja salasanan voimassaoloaikaa.

Vahvuusmittarit: Salasanavahvuusmittareilla (password strength meter, PSM) on sama päämäärä kuin salasanapolitiikoilla. Niiden tarkoitus on auttaa valitsemaan vahvempia salasanoja. Vahvuusmittarit antavat yleensä visuaalista palautetta salasanan vahvuudesta tai laskevat vahvuudelle pisteet. Vahvuusmittarit auttavat kuitenkin vain rajoitetusti heikkojen salasanojen ja salasanojen uudelleenkäytön aiheuttamiin ongelmiin. Lisäksi vahvuusmittari voi hämmentää, koska eri palveluissa voi olla erilaiset vahvuusmittarit ja yhdessä palvelussa “vahva” salasana voikin tulla luokitelluksi eri lailla jossakin toisessa palvelussa. Tämä voi hämmentää käyttäjää, eikä välttämättä auta hyvin salasanojen muodostamisessa.

Salasananhallintaohjelmat: Salasananhallintaohjelmat voivat auttaa käyttäjiä luomaan, tallentamaan ja hakemaan vahvoja salasanoja. Vahvat salasanat luodaan ja tallennetaan käyttämällä turvallisia satunnaislukugeneraattoreita ja suojattua salausta. Salasananhallintaohjelmia on monenlaisia: paikallisesti asennettavia sovelluksia, online-palveluita tai paikallisia laitteita. Vaikka ne voivat auttaa käyttäjiä käyttämään monipuolisempia ja vahvempia salasanoja, niiden vaikutus yleiseen salasanaturvallisuuteen on rajoitettu esim. käytettävyysongelmien vuoksi. Salasananhallintaohjelmat ovat tavallisille käyttäjille usein vaikeita ottaa käyttöön. Lisäksi voi olla vaikea valita itselleen sopivaa useista vaihtoehdoista. Käyttöönottovaiheen jälkeen ne kuitenkin helpottavat salasanojen hallintaa. Jos salasananhallintaohjelman käyttöönotto kiinnostaa, tällä ohjeella pääset alkuun. Huomaa, että on tärkeää valita hallintaohjelman pääsalasanaksi erittäin vahva, mutta silti muistettavissa oleva salasana, sillä kaikki muut salasanat suojataan sillä.

Monivaiheinen tunnistautuminen: Monivaiheinen tunnistautuminen vaatiii käyttäjää esittämään useita tekijöitä autentikointiprosessin aikana. Verkkosivustojen salasanoja täydennetään usein kaksivaiheisella autentikoinnilla (2FA). Tyypillisesti täydentäjä on mobiililaite. Salasanan lisäksi käyttäjä saa kertaluonteisen tokenin autentikointia varten mobillilaitteestaan.

WebAuthn (syventävä): WebAuthn (Web Authentication) -verkkostandardi on FIDO2-projektin ydinkomponentti, ja sen tavoitteena on tarjota standardoitu käyttöliittymä verkkokäyttäjien käyttäjien autentikointiin web-pohjaisissa sovelluksissa, jotka käyttävät julkisen avaimen salausta. WebAuthnia tukevat useimmat nykyaikaiset verkkoselaimet ja mobiilikäyttöjärjestelmät. Sitä voidaan käyttää yksi- tai monivaiheeseen autentikointiin, joka tukee PIN-koodeja, tunnuskoodeja, pyyhkäisykuvioita tai biometrisiä tietoja.

OAuth (syventävä): Vaikka Open Authorization (OAuth) ei ole autentikointimekanismi, sitä voidaan käyttää yksityisyyttä suojaavaan autentikointiin ja käyttäjien valtuutukseen kolmannen osapuolen verkkosovelluksiin. OAuth käyttää tokeneita sen sijaan, että se vaatisi käyttäjiltä kirjautumistietoja. OAuth-palveluntarjoajat tarjoavat käyttäjille pääsytokeneita, jotka valtuuttavat tiettyjen tilitietojen jakamisen kolmannen osapuolen sovellusten kanssa. Uudemmat OAuth-protokollan seuraajat, esim. OAuth 2 tai OpenID Connect, tukevat myös federoitua pääsynhallintaa. Suuret verkkopalveluiden tarjoajat, kuten Google tai Facebook, voivat toimia tunnistuspalveluina (identity provider), mikä auttaa käyttäjiä vähentämään kirjautumistietojen ja tilien määrää. Vaikka tällaisten protokollien tarkoituksena on parantaa tietoturvaa, on kuitenkin todettu, että protokollien oikea ja turvallinen toteutus on vaikeaa ja virheet saattavat mahdollistaa erilaisia toisena henkilönä esiintymishyökkäyksiä.