Ydintoimintojen priorisointi
Kun digitaalisia palveluita kehitetään, niille on aina budjetti. Tyypillistä on, että budjetti ei riitä ihan kaikkeen mihin haluttaisiin ja on tehtävä priorisointeja. Palveluiden kehittämisessä kärkeen nousevat uudet ominaisuudet, joilla voidaan lisätä myyntiä tai tehostaa olemassa olevia toimintoja. Jokunen prosentti budjetista varataan toki myös asiakaspalautteen kautta tuleville asioille. Sivustojen ydintoiminnot, kuten salasanan palautus, eivät oikein osu kumpaankaan kategoriaan ja siksi saattaakin joskus sattua tilanne, jossa koko palvelu on muuten modernisoitu, mutta salasanan palautus on yhä toteutettu vanhojen käytäntöjen mukaisesti.
Case esimerkki: "verkkopalvelu-x"
Teimme tietoturvatarkastuksen noin viisi vuotta vanhalle verkkopalvelulle, joka sisälsi paljon asiakas- ja omaisuustietoa. Tutkimme salasanan palautusta käyttöliittymän kautta ja se vaikutti hyvin toteutetulta. Yritimme syöttää [email protected] sähköpostiosoitetta käyttäjätunnukseksi, mutta palvelu ei paljastanut oliko tunnus olemassa vai ei. Tiesimme, että palvelu lähettää käyttäjälle linkin, jonka kautta voi asettaa uuden salasanan, mutta linkkikin vaikutti hyvin toteutetulta. Siitä oli nähtävissä user ID (123), mutta salaista tokenia (punaisella kuvassa) emme pystyneet hyödyntämään, emmekä väärentämään.
Esimerkki salasanan resetointilinkistä.
Palvelinkutsujen tasolla oletuksemme oli, että palvelimelta tuleva vastaus käyttäjän salasananpalautuskyselyyn ei myöskään paljastaisi mitään. Yllätyksemme olikin suuri, kun palvelin vastasi, että käyttäjä löytyy ja palautti myös käyttäjän ID:n sekä salaisen tokenin.
Palvelimen vastaus palautti kaikki salasanan resetointilinkkiin tarvittavat tiedot.
Näillä tiedoilla pystyimme muodostamaan salasananpalautuslinkin [email protected] käyttäjälle ja kirjautumaan sisään uudella salasanalla ylläpitäjän tunnuksin. Mikä pahinta, olisimme pystyneet tällä toiminnallisuudella myös selvittämään kaikkien palvelussa olevien käyttäjien tunnukset, vaihtamaan heidän salasanansa ja kirjautumaan sisään tarkastelemaan heidän tietojaan.
Kiire - tietoturvan pahin vihollinen
Vika saatiin nopeasti korjattua, ja kun juttelimme tilanteesta kehittäjien kanssa, syyksi paljastui kiire. Julkaisu oli mennyt viime tippaan ja tärkeintä siinä hetkessä oli liiketoiminnan ja asiakkaan kannalta olennaisten toimintojen toimivuus. Tuotantoon lipsahti versio, jossa oli mukana kehityksen tukena käytetty toiminnallisuus.
En kirjoittaisi tästä aiheesta, ellemme olisi valkohattuhakkereina törmänneet vastaaviin tilanteisiin useamman kerran viimeisen kahden vuoden aikana. Budjetteihin ja aikatauluihin emme voi vaikuttaa, mutta onnistuisimmeko vaikuttamaan sinuun? Jos sinulla on valta päättää ja tehdä valintoja, niin muistaisitko joskus huomioida myös salasanan palautusta? Se tekee tunnollisesti ja väsymättömästi työtään ja ansaitsisi aina välillä hieman rakkautta.
Luitko jo blogisarjan muut osat API tietoturvasta ja oletustunniksista?
Asiantuntijablogit
Anne Hautakangas
Kirjoittaja työskentelee Instassa kyberturvallisuuden asiantuntijana.
