Kuvittele, että joku huijaa kävijän klikkaamaan linkkiä, kun hän on kirjautuneena pankkitililleen. Linkki johtaa piilotettuun lomakkeeseen, joka kävijän tietämättä lähettää pankille pyynnön siirtää rahaa. Pankki näkee oikeaksi näyttävän pyynnön kirjautuneelta käyttäjältä ja käsittelee sen. Hyökkääjä on nyt siirtänyt rahaa uhrin tililtä tietämättä koskaan tämän salasanaa.
Tätä CSRF (Cross-Site Request Forgery) tarkoittaa: hyökkäys, jossa hyökkääjä saa uhrin tietämättään lähettämään lomakkeen tai pyynnön toiselle verkkosivustolle, jolle uhri on jo kirjautunut.
Tässä opit: mitä CSRF-hyökkäykset ovat ja miten ne toimivat, miksi ne ovat vaarallisia silloinkin, kun muita suojauksia on käytössä, miten CSRF-tunnisteet estävät ne ja miten suojaus otetaan käyttöön lomakkeissasi.
Mikä CSRF on?
CSRF (äännetään englanniksi "sea-surf") tulee sanoista Cross-Site Request Forgery. Se on hyökkäys, joka hyödyntää sitä, että kun olet kirjautuneena verkkosivustolle, selaimesi luottaa istuntoosi ja lisää sen automaattisesti jokaiseen sivustolle tekemääsi pyyntöön, vaikka pyyntö tulisi toiselta verkkosivustolta.
Hyökkäys toimii huijaamalla kirjautunutta kävijää lähettämään tietämättään lomake verkkosivustolle, jolla hänellä on tili. Hyökkääjä ei näe uhrin salasanaa. Sitä ei tarvitakaan. Hänen tarvitsee vain saada uhri tekemään pyyntö (esimerkiksi lähettämään piilotettu lomake) silloin, kun uhri on jo kirjautuneena, ja pyyntö tekee jotain, mitä hyökkääjä haluaa.
CSRF eroaa muista hyökkäyksistä, koska se ei vaadi tunnusten varastamista tai salauksen murtamista. Se hyödyntää uhrin luottamusta verkkosivustoon. Uhri on jo tunnistautunut, joten verkkosivusto luottaa pyyntöihin, jotka näyttävät tulevan häneltä.
Miten CSRF-hyökkäykset toimivat
CSRF-hyökkäys tapahtuu kolmessa vaiheessa.
Vaihe 1: uhri on kirjautuneena sivustollesi
Joku käy verkkosivustollasi ja kirjautuu tililleen. Hänen selaimessaan on nyt aktiivinen istuntoeväste, joka todistaa hänen tunnistautumisensa. Istunto pysyy aktiivisena niin kauan kuin hän käyttää sivustoa.
Vaihe 2: hyökkääjä huijaa hänet haitalliselle sivulle
Ollessaan yhä kirjautuneena sivustollesi uhri käy sivulla, jota hyökkääjä hallitsee (ehkä linkki sosiaalisesta mediasta, harhaanjohtava mainos tai aidolta näyttävä verkkosivusto). Sivulla on piilotettua koodia, joka lähettää lomakkeen takaisin sivustollesi.
Vaihe 3: lomake lähtee automaattisesti uhrin istunnolla
Piilotettu lomake lähetetään verkkosivustollesi. Koska uhri on jo kirjautuneena, hänen selaimensa lisää pyyntöön automaattisesti istuntoevästeen. Lomakkeesi näkökulmasta tämä on aito pyyntö tunnistautuneelta käyttäjältä. Lomake käsittelee sen niin kuin uhri olisi lähettänyt sen tarkoituksella.
Hyökkääjä on nyt tehnyt sivustollasi jotain uhrin tilillä uhrin tietämättä. Hän on voinut vaihtaa salasanan, siirtää rahaa, päivittää profiilin tai lähettää tietoja.
Miksi tämä toimii, vaikka muita suojauksia on käytössä
CSRF-hyökkäykset ohittavat useita yleisiä suojausominaisuuksia:
HTTPS ei pysäytä CSRF:ää. Tieto on salattu siirron aikana, mutta hyökkääjän ei tarvitse siepata sitä. Hän lähettää pyynnön uhrin selaimesta, ja uhrin selain luottaa jo siihen.
Salasanasuojaus ei pysäytä CSRF:ää. Hyökkääjä ei koskaan tarvitse uhrin salasanaa. Hän hyödyntää vain sitä, että uhri on jo kirjautuneena.
Vahva kirjautumisjärjestelmä ei pysäytä CSRF:ää. Vaikka tunnistautuminen olisi täydellinen, hyökkäys toimii, jos uhri on kirjautuneena.
Siksi CSRF-suojaus on oma kerroksensa. Muut suojaukset eivät estä sitä. Lomakkeet pitää suunnitella erikseen kestämään CSRF-hyökkäykset.
CSRF-tunnisteet: näin ne pysäyttävät hyökkäyksen
Ratkaisu on CSRF-tunniste. Se on yksilöllinen, arvaamaton merkkijono, jonka palvelimesi luo jokaiselle lomakkeelle. Näin se toimii:
Palvelimesi luo yksilöllisen tunnisteen jokaiselle kävijälle
Kun joku lataa lomakkeen sisältävän sivun, palvelimesi luo satunnaisen tunnisteen ja liittää sen kyseisen käyttäjän istuntoon. Tunniste on joka kerta erilainen ja yksilöllinen kyseiselle käyttäjälle.
Tunniste upotetaan lomakkeeseen
Tunniste lisätään HTML-lomakkeeseen piilotettuna kenttänä. Kun kävijä lähettää lomakkeen, tunniste kulkee mukana.
Palvelimesi tarkistaa tunnisteen ennen lähetyksen käsittelyä
Kun lomake lähetetään, palvelimesi tarkistaa, vastaako lähetyksen tunniste sitä tunnistetta, jonka loit tämän käyttäjän istuntoon. Jos vastaa, lomake käsitellään. Jos ei vastaa (tai tunnistetta ei ole), lomake hylätään.
Hyökkääjän piilotettu lomake ei voi sisältää kelvollista tunnistetta, koska tunnisteet ovat arvaamattomia ja yksilöllisiä jokaiselle istunnolle. Toisen verkkotunnuksen hyökkääjä ei voi nähdä tai arvata tunnistetta. Siksi hyökkäys epäonnistuu. Piilotettu lomake lähtee, mutta palvelimesi hylkää sen, koska tunniste ei täsmää.
Miltä CSRF-tunniste näyttää käytännössä
HTML:ssä CSRF-suojattu lomake näyttää tältä:
<form method="POST" action="/submit-form"> <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"> <input type="email" name="email" placeholder="Sähköpostisi"> <button type="submit">Lähetä</button> </form>Kenttä `csrf_token` on piilotettu. Kävijä ei näe sitä, mutta se lähtee lomakkeen tietojen mukana. Palvelimesi tarkistaa sen ennen sähköpostin tai muiden tietojen käsittelyä.
CSRF-suojaus eri lomaketyypeille
Perinteiset HTML-lomakkeet
Tavalliset HTML-lomakkeet (ne, jotka lähettävät tietoja palvelimellesi POST-pyynnöllä) tarvitsevat CSRF-tunnisteet. Tähän kuuluvat yhteydenottolomakkeet, kirjautumislomakkeet, salasanan palautuslomakkeet ja kaikki lomakkeet, jotka muuttavat tietoja palvelimellasi.
AJAX- ja JavaScript-lomakkeet
JavaScriptillä rajapintaan lähetettävät lomakkeet tarvitsevat myös CSRF-suojan. Tunniste voidaan upottaa itse lomakkeeseen, tallentaa evästeeseen tai hakea meta-tunnisteesta ennen pyynnön lähettämistä.
Tilattomat rajapintapyynnöt
Jos rajapintasi käyttää tunnistepohjaista tunnistautumista (kuten JWT), CSRF-suojaus toimii eri tavalla. Selain ei voi liittää JWT-tunnistetta automaattisesti samalla tavalla kuin istuntoevästettä, joten perinteinen CSRF on pienempi uhka. Paras käytäntö on silti lisätä ylimääräinen CSRF-tunniste lisäsuojaksi.
Muut suojaukset, jotka toimivat CSRF-tunnisteiden kanssa
CSRF-tunnisteet ovat ensisijainen puolustus, mutta ne toimivat parhaiten yhdessä muiden tietoturvakäytäntöjen kanssa.
SameSite-evästeet
Kun asetat istuntoevästeen, voit lisätä siihen `SameSite`-määrityksen, joka käskee selainta olemaan lisäämättä evästettä pyyntöihin, jotka tulevat toiselta verkkotunnukselta. Tämä estää hyökkääjän piilotettua lomaketta käyttämästä uhrin istuntoa lainkaan.
Referer-otsikon tarkistukset
Palvelimesi voi tarkistaa Referer-otsikon nähdäkseen, mistä pyyntö tuli. Jos lomakkeen lähetys väittää tulevansa verkkotunnuksestasi, mutta Referer näyttää toisen verkkotunnuksen, kyseessä on todennäköisesti hyökkäys. (Referer-otsikoita voi kuitenkin väärentää, joten tämä ei ole täydellinen suoja.)
Double-submit-evästemalli
Tässä tavassa CSRF-tunniste tallennetaan sekä evästeeseen että lomakkeen kenttään. Palvelimesi tarkistaa, että ne täsmäävät, ennen käsittelyä. Tämä on harvinaisempi kuin perinteinen tunniste, mutta toimii hyvin tilattomissa sovelluksissa.
Miten CSRF-suojaus otetaan käyttöön
Toteutuksen yksityiskohdat riippuvat teknologiastasi, mutta toimintatapa on sama:
- Luo yksilöllinen tunniste istuntoa kohti. Kun käyttäjä aloittaa istunnon tai lataa lomakesivun, taustajärjestelmäsi luo uuden tunnisteen.
- Tallenna tunniste palvelimelle. Tallenna se kyseisen käyttäjän istunnon yhteyteen.
- Lisää tunniste lomakkeeseen. Lisää se piilotettuna kenttänä HTML:ään tai meta-tunnisteena, jonka JavaScript voi lukea.
- Tarkista lähetettäessä. Ennen lomakkeen tietojen käsittelyä tarkista, että lähetetty tunniste vastaa kyseisen istunnon tallennettua tunnistetta.
- Luo uusi tunniste arkaluonteisten toimintojen jälkeen. Kun käyttäjä vaihtaa salasanansa tai tekee jotain kriittistä, luo uusi tunniste.
Useimmat nykyaikaiset sovelluskehykset hoitavat CSRF-tunnisteiden luonnin ja tarkistuksen automaattisesti. Jos käytät sovelluskehystä, CSRF-suojaus on yleensä oletuksena päällä. Varmista vain, ettet vahingossa poista sitä käytöstä.
Yleiset virheet, jotka jättävät lomakkeet haavoittuviksi
CSRF-suojauksen poistaminen mukavuuden vuoksi. Jotkin kehittäjät poistavat CSRF-tarkistukset käytöstä helpottaakseen rajapinnan testausta tai yksinkertaistaakseen koodiaan. Älä tee niin. Se luo todellisen haavoittuvuuden.
Saman tunnisteen käyttö kaikille käyttäjille. Tunnisteen täytyy olla yksilöllinen jokaisen käyttäjän istunnolle. Tunniste, joka on sama kaikille (tai sama kaikille käyttäjille kaikkina päivinä), ei suojaa CSRF:ltä.
Tunnisteiden uusimatta jättäminen. Jos käytät samaa tunnistetta viikkoja, hyökkääjällä on enemmän aikaa hyödyntää sitä. Uusi tunnisteet säännöllisesti ja aina arkaluonteisten toimintojen jälkeen.
Pelkkiin SameSite-evästeisiin luottaminen. SameSite auttaa, mutta ei riitä yksin. Käytä CSRF-tunnisteita ensisijaisena suojana ja SameSitea varmistuksena.
Tunnisteiden unohtaminen joistakin lomakkeista. Jos suojaat osan lomakkeista tunnisteilla mutta et toisia, hyökkääjät käyttävät suojaamattomia lomakkeita. Jokainen tietoja muuttava lomake tarvitsee suojan.
Mitä WEMASY tekee CSRF-suojauksen eteen
WEMASYn lomakkeisiin tulee automaattisesti CSRF-tunnistesuojaus jokaiselle luomallesi lomakkeelle. Sinun ei tarvitse määrittää sitä tai ajatella sitä. Kun kävijä lähettää lomakkeen, WEMASY tarkistaa tunnisteen ennen lähetyksen tallentamista. Tämä suojaus on sisäänrakennettu ja oletuksena käytössä.
Lue lisää lomakkeiden suojausvaihtoehdoista hinnoittelusivulta.