Miksi salasanan palautuksen testaus jää huomiotta

Salasanan palautus on yksi hyökätyimmistä kuluista missä tahansa sovelluksessa — ja paradoksaalisesti yksi vähiten testatuista. Syy on yksinkertainen: kehittäjät käyttävät omaa sähköpostiosoitettaan kehityksen aikana. Kolmannen tai neljännen testiajon jälkeen saapuneet-kansiosi on hautautunut "Palauta salasanasi" -viesteihin, jotka näyttävät kaikki samanlaisilta. Aihekentät sekoittuvat toisiinsa, menetät otteen siitä, mikä linkki kuuluu mihinkin ajoon, ja lopulta testaamisesta tulee liian kiusallista tehdä perusteellisesti. Alat luottaa oletukseen, että se toimii, koska se toimi viime kerralla. Juuri tällainen omahyväisyys päästää vakavia bugeja tuotantoon.

Panokset ovat korkeat. Salasanan palautus on ensisijainen mekanismi, jolla käyttäjät palauttavat tilinsä — ja jolla hyökkääjät yrittävät kaapata ne. Puutteellinen token, joka ei vanhene, uudelleen käytettävä linkki tai palautuspäätepiste ilman nopeusrajoitusta voi muuttaa pienen tunnistetietovuodon täydeksi tilin kaappaukseksi. Have I Been Pwned -palvelun indeksoimien tietojen mukaan miljardit vanhoista tietomurroista peräisin olevat tunnistetiedot ovat aktiivisesti liikkeellä, ja hyökkääjät yrittävät rutiininomaisesti salasanan palautuksia löytämiään tilejä vastaan. Jos palautuskulussasi on heikkouksia, he löytävät ne.

Mitä sinun on todella testattava salasanan palautuskulussa

Peruskokeilu siitä, "lähettääkö se sähköpostin", ei riitä. OWASP Authentication Cheat Sheet hahmottelee kattavan joukon vaatimuksia turvalliselle salasanan palautukselle, ja jokainen niistä ansaitsee oman testauksensa. Tässä on täydellinen lista siitä, mitä sinun tulisi todella todentaa:

• Sähköpostin toimitus — saapuuko palautussähköposti, ja saapuuko se ripeästi? Palautussähköposti, joka kestää 10 minuuttia, hämmentää käyttäjiä ja synnyttää tukipyyntöjä.
• Linkin oikeellisuus — johtaako sähköpostin linkki oikealle sivulle oikean tokenin kanssa URL-osoitteessa tai leipätekstissä?
• Tokenin vanheneminen — jos odotat 25 tuntia ja klikkaat sitten linkkiä, hylkääkö sovellus oikein vanhentuneen tokenin? Testaa tämä nimenomaisesti, ei teoreettisesti.
• Kertakäytön valvonta — voitko klikata samaa palautuslinkkiä kahdesti? Onnistuneen salasanan vaihdon jälkeen tokenin on mitätöidyttävä. Tämä on OWASPin mukaan pakollinen vaatimus, ja se ohitetaan usein.
• Mitätöinti uudelleenpyynnön yhteydessä — jos käyttäjä pyytää palautusta ja pyytää sitten toisen palautuksen kaksi minuuttia myöhemmin, mitätöityykö ensimmäinen token? Molempien tokenien voimassaolo samanaikaisesti on tietoturvavirhe.
• SSO-tilien käsittely — mitä tapahtuu, kun Googlen, GitHubin tai muun OAuth-tarjoajan kautta rekisteröitynyt käyttäjä pyytää salasanan palautusta? Tämä kulku on usein rikki, koska tilillä ei ole paikallista salasanaa palautettavaksi.
• HTTPS:n pakotus — käyttääkö palautuslinkki HTTPS:ää? Tavallisen HTTP:n yli kulkeva palautuslinkki paljastaa tokenin verkon salakuuntelulle.
• Virheilmoitusten laatu — kun linkki on vanhentunut, näyttääkö sovellus selkeän, hyödyllisen viestin vai geneerisen 500-virheen? Käyttäjäkokemuksella on tässä merkitystä.
• Nopeusrajoitus — mitä tapahtuu, jos joku lähettää 10 palautuspyyntöä samalle osoitteelle minuutissa? Pitäisi olla järkevä raja, joka estää luetteloinnin ja väärinkäytön.
• Sähköpostin luetteloinnin esto — eroaako vastaus sen perusteella, onko sähköpostiosoite järjestelmässä? Erilainen vastaus on tietovuoto, joka antaa hyökkääjien luetteloida voimassa olevat tilit.

Väliaikaisen sähköpostin lähestymistapa — vaiheittainen läpikäynti

Siistein ratkaisu kaikkiin näihin testaushaasteisiin on tuore väliaikainen sähköposti-osoite jokaista testiajoa varten. Näin se toimii käytännössä.

Avaa väliaikainen saapuneet-kansio, kopioi ylhäällä näkyvä osoite ja siirry sovellukseesi. Rekisteröi uusi testitili tuota osoitetta käyttäen. Siirry kirjautumissivulle ja klikkaa "Unohtuiko salasana". Syötä osoite ja lähetä pyyntö. Vaihda takaisin väliaikaiseen saapuneet-kansioon — palautussähköposti saapuu reaaliajassa, tyypillisesti muutamassa sekunnissa. Voit nähdä koko sähköpostin, tarkastaa aihekentän ja lähettäjän tiedot, klikata linkkiä, todentaa, että se johtaa oikealle sivulle, asettaa uuden salasanan ja vahvistaa, että kirjautuminen toimii. Kokonaisaika alusta loppuun: alle kaksi minuuttia. Kun sinun täytyy testata toinen skenaario, avaa uusi selaimen välilehti — saat täysin riippumattoman saapuneet-kansion eri osoitteella. Ei siivousta, ei ketjujen aiheuttamaa sekaannusta, ei riskiä klikata vahingossa väärää linkkiä aiemmasta ajosta.

Tosielämän esimerkkiläpikäynti: testaus ennen julkaisua

Valmistelin SaaS-sovellusta pieneen julkaisuun, joka sisälsi päivityksen tunnistautumiskirjastoon. Salasanan palautuskulkua ei ollut nimenomaisesti muutettu, mutta auth-kirjaston päivityksillä on tapana hiljaisesti rikkoa sähköpostitokenien generointi. Tässä on koko sarja, jonka kävin läpi.

Avasin viisi selaimen välilehteä, kukin oman riippumattoman väliaikaisen saapuneet-kansionsa kanssa. Välilehti yksi: onnistumispolku — rekisteröi, pyydä palautus, käytä linkkiä kahdessa minuutissa, vahvista kirjautuminen. Välilehti kaksi: vanhentunut token — rekisteröi, pyydä palautus, odota sähköpostin saapumista, jätä se sivuun 25 tunniksi (palasin siihen seuraavana päivänä) ja kokeilin sitten linkkiä. Sovellus hylkäsi sen oikein. Välilehti kolme: kaksinkertainen palautus — rekisteröi, pyydä palautus, pyydä heti palautus uudelleen ja kokeilin sitten molempia linkkejä. Ensimmäisen linkin olisi pitänyt mitätöityä; niin se olikin. Välilehti neljä: käytetyn linkin uudelleenkäyttö — rekisteröi, pyydä palautus, käytä linkkiä salasanan vaihtamiseen onnistuneesti, ja kokeilin sitten samaa linkkiä toisen kerran. Hylätty oikein. Välilehti viisi: nopeusrajoitus — käynnistin palautuspyyntöjä nopeasti todentaakseni, että nopeusrajoitin toimi.

Jokainen skenaario käytti puhdasta, riippumatonta saapuneet-kansiota. Ei ollut epäselvyyttä siitä, mikä sähköposti kuului mihinkin testiin. Auth-kirjaston päivitys ei ollut rikkonut mitään, ja minulla oli dokumentoitu todiste. Koko testiajo kesti noin 30 minuuttia, mukaan lukien yön yli kestänyt vanhentuneen tokenin tarkistus.

Reunatapausten testaus useilla väliaikaisilla saapuneet-kansioilla samanaikaisesti

Jokainen selaimen välilehti väliaikaisessa sähköpostipalvelussa on riippumaton saapuneet-kansio omalla ainutkertaisella osoitteellaan. Tämä tekee rinnakkaisesta testauksesta suoraviivaista. Avaa kolme välilehteä, ja sinulla on kolme ainutkertaista osoitetta. Rekisteröi kolme testitiliä, käynnistä salasanan palautukset kaikille kolmelle samanaikaisesti ja todenna, että kukin tili saa vain oman tokeninsa — ei jonkun toisen. Tämä ristikontaminaatiotesti nappaa erityisen ikävän bugin, jossa huonosti toteutettu palautusjärjestelmä lähettää kaikki tokenit ensin rekisteröidylle osoitteelle tai kovakoodattuun osoitteeseen väärin määritetyssä ympäristössä.

Voit myös testata, mitä tapahtuu, kun käyttäjä pyytää palautusta ollessaan jo kirjautuneena, tai mitä tapahtuu, kun palautusta pyydetään sähköpostiosoitteelle, jota ei ole järjestelmässä. Jokainen näistä reunatapauksista saa oman puhtaan saapuneet-kansionsa, oman puhtaan tilansa ja tuottaa yksiselitteisiä tuloksia.

Tokenin turvallisuuden tarkistuslista

Salasanan palautustokenit ovat yksi yleisimmistä hyökkäyspinnoista verkkosovelluksissa. OWASP on selväsanainen siitä, mitä turvallinen toteutus vaatii, ja rima on korkeammalla kuin monet tiimit tajuavat. Jokaisen tämän listan kohdan tulisi olla todennettavissa testiesi kautta:

• Vähintään 32 merkkiä, kryptografisesti satunnainen — lyhyet tai ennakoitavat tokenit voidaan murtaa raa'alla voimalla. Käytä alustasi kryptografisesti turvallista satunnaislukugeneraattoria, ei Math.random()-funktiota tai vastaavia.
• Vanhenee 24 tunnin sisällä, ihanteellisesti 1 tunnissa — token, joka ei koskaan vanhene, on pysyvä hyökkäyspinta. Yksi tunti on suositeltu maksimi useimmille sovelluksille.
• Vain kertakäyttöinen — token on mitätöitävä sillä hetkellä, kun se lunastetaan. Uudelleen käytettävä palautustoken on kriittinen haavoittuvuus.
• Mitätöidään, kun uusi palautus pyydetään — jos käyttäjä pyytää palautusta uudelleen, kaikki aiemmat kyseisen tilin voimassa olevat tokenit on mitätöitävä.
• Nopeusrajoitettu sähköpostiosoitetta kohti — estä automatisoitu luettelointi ja väärinkäyttö rajoittamalla, kuinka monta palautuspyyntöä voidaan tehdä osoitetta kohti aikaikkunassa.
• Ei koskaan kirjata selkokielisenä — jos loki-infrastruktuurisi tallentaa pyyntöparametreja, varmista, että palautustokenit suljetaan pois tai hajautetaan ennen kirjaamista.

Miltä itse palautussähköpostin tulisi näyttää

Palautussähköpostin sisällöllä ja esitystavalla on enemmän merkitystä kuin useimmat tiimit ymmärtävät. Hyvin laadittu palautussähköposti on selkeä ja toimiva: selkeä aihekenttä ("Palauta salasanasi"), yksi näkyvä painike tai linkki, selkeä vanhenemismaininta ("Tämä linkki vanhenee 1 tunnissa") ja huomautus siitä, että jos käyttäjä ei pyytänyt tätä, hän voi turvallisesti jättää sähköpostin huomiotta. Ei markkinointitekstiä, ei sosiaalisen median kuvakkeita, ei uutiskirjeen alatunnistetta. Tapahtumasähköpostin tulisi näyttää tapahtumasähköpostilta.

Myös lähettäjän tiedoilla on merkitystä. Lähettäjän nimen tulisi vastata brändiäsi selkeästi, ja lähettäjän osoitteen tulisi olla kunnolla todennettu. Sähköposti, joka saapuu epäsopivalla lähettäjän nimellä tai joka päätyy roskapostikansioon huonon todennuskonfiguraation vuoksi, aiheuttaa todellista käyttäjien hämmennystä ja tukikuormaa. Tarkista verkkotunnuksesi SPF-, DKIM- ja DMARC-konfiguraatio työkalulla kuten MXToolbox, ja lue sähköpostin todennusopas, jos jokin näistä termeistä on tuntematon.

Tekninen sähköpostimäärittely — mikä on ja mikä ei ole voimassa oleva sähköposti, miten toimitus toimii päästä päähän — on dokumentoitu asiakirjassa RFC 5321. Se on tiivistä luettavaa, mutta yleiskatsausosiot ovat hyödyllistä kontekstia sen ymmärtämiseksi, mitä sähköposti-infrastruktuurisi todella tekee lähettäessään palautussähköpostin.

Miksi oikea saapuneet-kansiosi on väärä työkalu tähän

Henkilökohtaisen tai työsähköpostiosoitteesi käyttäminen testitileihin luo joukon ongelmia hankaluuden lisäksi. Osoitteesi päätyy oman sovelluksesi tietokantaan testitietueena. Se saattaa esiintyä sovelluslokeissa, sähköpostipalvelimesi lähetettyjen historiassa, staging-ympäristön viennissä ja toisinaan tietokantavedoksissa, joita jaetaan urakoitsijoille tai ulkoisille QA-tiimeille. Staging-ympäristöissä on usein löyhemmät käyttöoikeudet kuin tuotannossa. Electronic Frontier Foundation ajaa tietojen minimointia perustavanlaatuisena yksityisyyden periaatteena — todellisen osoitteesi pitäminen poissa kehitys- ja testijärjestelmistä on tuon periaatteen suora sovellus. Väliaikainen saapuneet-kansio vanhenee luonnostaan, sitä ei koskaan liitetä henkilöllisyyteesi eikä se jätä jälkeä.

Sisällytä salasanan palautus regressiotestisarjaasi

Salasanan palautus on sellainen kulku, joka rikkoutuu hiljaisesti, kun tunnistautumiskirjastoja päivitetään, kun sähköpostipalveluntarjoajia vaihdetaan tai kun API-avaimia uusitaan. Sillä on harvoin omia automaattisia testejä, koska useimmat tiimit pitävät sitä vain käyttöliittymän integraatiotestinä, jota on vaikea automatisoida. Tuo perustelu on ymmärrettävä mutta vaarallinen.

Vähintään kannattaa harkita perustavanlaatuisen päästä päähän -testin lisäämistä staging- tai CI-ympäristöösi: luo ohjelmallisesti testitili generoidulla osoitteella, käynnistä palautuspyyntö, sieppaa tai tarkasta lähtevä sähköposti suoraan sähköpostipalvelusi API:sta, poimi token, yritä lunastusta ja todenna tuloksena syntyvä tila. Tämän ei tarvitse olla monimutkaista. Jopa yksi automaattinen tarkistus, joka vahvistaa palautuskulun toimivuuden jokaisen käyttöönoton jälkeen, nappaa yleisimmän regressioluokan: auth-riippuvuuksien muutokset, jotka rikkovat tokenien generoinnin hiljaisesti.

Lisäresursseja turvalliseen tunnistautumiseen

Laajemman näkökulman saamiseksi siihen, miksi turvallisella salasanojen käsittelyllä on käytännössä merkitystä, Troy Hunt käsittelee tosielämän tietomurtojen analyysia helposti lähestyttävällä ja hyvin todistetulla tarkkuudella. Hänen kirjoituksensa tunnistetietojen täyttöhyökkäyksistä ja tilien kaappauksesta ovat suoraan relevantteja sen kannalta, miksi palautuskulku ansaitsee vakavaa huomiota. OWASP Authentication Cheat Sheet on edelleen kattavin yksittäinen viite kaikelle, mitä tunnistautumisjärjestelmäsi tulisi tehdä. Näiden kahden resurssin ja kurinalaisen testauskäytännön avulla, joka käyttää tuoreita saapuneet-kansioita jokaiseen ajoon, sinulla on perusta tunnistautumisjärjestelmälle, joka kestää tosielämän tarkastelun.