Tarjoaa syvällistä tutkimusta Cross-Site Request Forgery (CSRF) -hyökkäyksistä, selittäen niiden toimintamekanismeja, näyttäen esimerkkejä ja yksityiskohtaisesti erilaisia ehkäisymenetelmiä verkkosovellusten turvallisuuden parantamiseksi.
Kun työskentelemme verkkokehityksen parissa, erityisesti evästeiden kanssa, kuulemme usein lauseita kuten "tämä asetus auttaa estämään CSRF." Kuitenkin monilla ihmisillä on vain epämääräinen käsitys siitä, mitä "CSRF" oikeasti tarkoittaa.
Tänään sukellamme syvemmälle CSRF:ään (Cross-Site Request Forgery), yleiseen verkkoturvallisuusaukkoon. Tämä auttaa meitä käsittelemään CSRF:ään liittyviä ongelmia tehokkaammin.
CSRF (Cross-Site Request Forgery) on eräänlainen verkkohyökkäys, jossa hyökkääjät huijaavat todennettuja käyttäjiä suorittamaan tahattomia toimintoja. Yksinkertaisesti sanottuna se on "hakkereita tekeytymässä käyttäjiksi suorittamaan luvattomia toimintoja".
Voidaksemme ymmärtää CSRF:ää, meidän on käsitettävä muutama avainkäsitys:
Samaperäisyyskäytäntö on selainten turvaominaisuus, joka rajoittaa, kuinka dokumentti tai skripti yhdestä alkuperästä voi olla vuorovaikutuksessa toisen alkuperän resurssien kanssa.
Alkuperä koostuu protokollasta (kuten HTTP tai HTTPS), verkkotunnuksen nimestä ja porttinumerosta. Esimerkiksi https://example.com:443 on yksi alkuperä, kun taas https://demo.com:80 on toinen.
Samaperäisyyskäytäntö rajoittaa tiedon saatavuutta eri alkuperien välillä, mikä tarkoittaa:
Kuitenkin verkkoyhteyksien avoimuuden ja yhteentoimivuuden ylläpitämiseksi (kuten resurssien lataaminen CDN:istä tai pyyntöjen lähettäminen kolmannen osapuolen API:hin lokitusta varten) samaperäisyyskäytäntö ei rajoita alkuperien välisiä verkkopyyntöjä:
<script>, <img>, <link>, <iframe>-elementit)Automaattinen evästeiden lähetysmekanismi on selainten tärkeä ominaisuus. Kun selain lähettää pyynnön verkkotunnukseen, se liittää automaattisesti kaikki tuon verkkotunnuksen evästeet. Tämä prosessi on automaattinen eikä vaadi mitään JavaScript-koodia tai käyttäjän vuorovaikutusta.
Tämä mekanismi mahdollistaa verkkosivustojen helposti muistavan käyttäjien kirjautumistilan, koska jokainen pyyntö kantaa automaattisesti käyttäjän identiteettitietoja.
Lihavoitu
Esimerkiksi, kun kirjaudut pankin verkkosivustoon (bank.com) ja saat identiteettievästeen, kun klikkaat nähdäksesi tiliotteesi, selain löytää automaattisesti kaikki bank.com:in kanssa vastaavat evästeet ja liittää ne pyyntöön. Pankin palvelin voi sitten tunnistaa sinut takapäästä ja palauttaa tiliotetietosi.
Käyttäjä kirjautuu kohde-verkkosivustolle (kuten pankkisivusto) ja saa todennusevästeen. Tämä vaihe käyttää automaattista evästeiden lähetysmekanismia. Kun pankkisivusto asettaa identiteettitodennusevästeen, selain liittää tämän evästeen automaattisesti jokaiseen tälle sivustolle lähetettyyn pyyntöön.
Ilman uloskirjautumista, käyttäjä vierailee haitallisella verkkosivustolla. Tässä vaiheessa samaperäisyyskäytännön vuoksi haitallinen sivusto ei voi suoraan lukea tai muokata pankkisivuston evästeet, mikä suojaa käyttäjän identiteettitiedot suoranaiselta varkaudelta.
Haitallinen sivusto sisältää pyynnön kohdesivustolle (kuten siirtotoimenpide).
Vaikka samaperäisyyskäytäntö rajoittaa alkuperien välistä pääsyä, se sallii alkuperien väliset verkkopyynnöt, kuten <img>, <form>-elementeillä aloitetut pyynnöt. Hyökkääjät hyödyntävät tätä "aukkoa".
Käyttäjän selain lähettää tämän pyynnön automaattisesti, mukana kohdesivuston eväste. Tämä on CSRF-hyökkäyksen ydin. Se hyödyntää sekä samaperäisyyskäytännön sallimia alkuperien välisiä pyyntöjä että automaattista evästeiden lähetysmekanismia (jopa haitallisten sivustojen aloittamat pyynnöt kantavat verkkotunnukseen vastaavat evästeet).
Kohdesivusto vastaanottaa pyynnön, varmistaa evästeen olevan kelvollinen ja suorittaa toimenpiteen. Palvelin ei voi tietää, tuleeko tämä pyyntö laillisesta käyttäjätoiminnasta, koska liitetty eväste on kelvollinen.
Kuvitellaan, miten CSRF-hyökkäys tapahtuu tietyllä esimerkillä. Käytämme kuvitteellista pankin verkkosivustoa bank.com.
Ensin käyttäjä vierailee https://bank.com ja kirjautuu tiliinsä.
Onnistuneen kirjautumisen jälkeen palvelin asettaa todennusevästeen, esimerkiksi:
Käyttäjä suorittaa siirtotoimenpiteen pankin verkkosivustolla, esimerkiksi siirtäen 1000 dollaria Alicelle. Tämä toimenpide voi lähettää pyynnön kuten:
Oletetaan nyt, että hyökkääjä luo haitallisen verkkosivuston https://evil.com sisältäen seuraavan HTML:n:
Kun käyttäjä klikkaa https://evil.com-linkkiä ilman, että on kirjautunut ulos pankkitililtään, koska hän on jo kirjautunut bank.com:iin, selaimella on kelvollinen session_id-eväste.
Kun paha sivu latautuu, se lähettää automaattisesti piilotetun lomakkeen, lähettäen siirtopyynnön https://bank.com/transfer.
Käyttäjän selain liittää automaattisesti bank.com:in evästeen tähän pyyntöön. Bank.com-palvelin vastaanottaa pyynnön, varmentaa evästeen olevan kelvollinen ja suorittaa tämän luvattoman siirtotoimenpiteen.
Tässä on joitakin yleisesti käytettyjä CSRF-puolustusmenetelmiä. Selitämme yksityiskohtaisesti kunkin menetelmän periaatteen ja miten se tehokkaasti estää CSRF-hyökkäyksiä:
CSRF-tokenit ovat yksi yleisimmistä ja tehokkaimmista metodeista puolustautua CSRF-hyökkäyksiä vastaan. Toimintamekanismi:
Koska CSRF-token on yksilöllinen arvo, joka on sidottu käyttäjän istuntoon, ja hyökkääjä ei voi tietää tai arvata tätä arvoa (koska se on erilainen jokaiselle istunnolle), vaikka hyökkääjä huijaisi käyttäjän lähettämään pyynnön, palvelin hylkää pyynnön, koska siinä ei ole kelvollista CSRF-tokenia.
Toteutusesimerkki:
Palvelinpuolella (käyttäen Node.js:ää ja Expressiä):
Etupään JavaScriptissä:
Referer-otsikon tarkistaminenReferer-otsikko sisältää pyynnön aloitussivun URL-osoitteen. Tarkistamalla Referer-otsikon palvelin voi määrittää, tuleeko pyyntö lailliselta lähteeltä.
Koska CSRF-hyökkäykset tulevat yleensä eri verkkotunnuksista, Referer-otsikko näyttää hyökkääjän verkkotunnuksen nimen. Tarkistamalla, onko Referer odotettu arvo, voidaan estää tuntemattomista lähteistä tulevat pyynnöt.
On kuitenkin huomattava, että tämä menetelmä ei ole täysin luotettava, koska jotkut selaimet saattavat olla lähettämättä Referer-otsikkoa, ja käyttäjät voivat poistaa Referer-otsikon selaimen asetuksilla tai laajennuksilla.
Toteutusesimerkki:
SameSite-evästeominaisuuden käyttöSameSite on evästeen ominaisuus, jota käytetään hallitsemaan, lähetetäänkö evästeitä alkuperien välisissä pyynnöissä. Sillä on kolme mahdollista arvoa:
Strict: Evästeitä lähetetään vain samaperäisissä pyynnöissä.Lax: Evästeitä lähetetään samaperäisissä pyynnöissä ja ylimmän tason navigoinnissa.None: Evästeitä lähetetään kaikissa alkuperien välisissä pyynnöissä (on käytettävä Yhdessä Secure-ominaisuuden kanssa).Kun SameSite on asetettu Strict:ksi, se voi täysin estää kolmannen osapuolen verkkosivustoja lähettämästä evästeitä, jolloin CSRF-hyökkäykset estetään tehokkaasti.
Jos SameSite on asetettu Lax:ksi, se suojaa herkkiä toimenpiteitä sallien kuitenkin joitakin tavallisia alkuperien välisiä käyttötapauksia (kuten verkkosivulle siirtymisen ulkoisista linkeistä).
Toteutusesimerkki:
AJAX-pyynnöissä voidaan lisätä mukautettuja pyyntöotsikoita. Samaperäisyyskäytännön rajoitusten vuoksi hyökkääjät eivät voi asettaa mukautettuja otsikoita alkuperien välisissä pyynnöissä. Palvelin voi tarkistaa tämän mukautetun otsikon olemassaolon varmistaakseen pyynnön laillisuuden.
Toteutusesimerkki:
Etupäässä:
Palvelinpuolella:
Kaksoisevästevarmennus on tehokas CSRF-puolustustekniikka. Sen keskeinen periaate on, että palvelin luo satunnaisen tokenin, asettaa sen sekä evästeenä että upottaa sen sivulle (yleensä piilotettuna lomakekenttänä). Kun selain lähettää pyynnön, se liittää evästeen automaattisesti, kun taas sivun JavaScript lähettää tokenin pyyntöparametrina. Palvelin sitten vahvistaa, vastaako evästeessä oleva token pyyntöparametrin tokenia.
Vaikka hyökkääjät voivat sisältää kohdesivuston evästeen alkuperien välisissä pyynnöissä, he eivät voi lukea tai muokata evästeen arvoa eikä päästä käsiksi tai muokata sivun tokenarvoa. Vaadittamalla, että pyyntö sisältää sekä evästeiden että parametrien tokenit, se varmistaa, että pyyntö tulee lähteestä, jolla on lupa lukea eväste, ja näin se puolustaa tehokkaasti CSRF-hyökkäyksiä vastaan.
Erityisen herkille toimenpiteille (kuten salasanan vaihtaminen tai suurten siirtojen tekeminen) voidaan vaatia käyttäjän uudelleentodennus.
Tämä antaa käyttäjille lisävarmistuksen turvallisuuspisteen. Vaikka käyttäjä onnistuisi aloittamaan CSRF-hyökkäyksen, hän ei voi ohittaa uudelleentodennusvaihetta.
Toteutusehdotukset:
Tämän syvällisen keskustelun avulla toivomme, että sinulla on nyt perusteellisempi ymmärrys CSRF-hyökkäyksistä. Emme ole ainoastaan oppineet, kuinka CSRF toimii, vaan myös tutkineet erilaisia tehokkaita puolustuskeinoja. Kaikki nämä menetelmät voivat tehokkaasti parantaa verkkosovellusten turvallisuutta.
Toivomme, että tämä tieto auttaa sinua paremmin käsittelemään CSRF:ään liittyviä ongelmia päivittäisessä kehityksessäsi ja rakentamaan turvallisempia verkkosovelluksia.