Tappasivatko SameSite-evästeet CSRF:n?

Vähensi sitä huomattavasti, mutta ei poistanut. SameSite=Lax (nykyaikainen oletus) sallii sivustojen väliset evästeet ylätason navigoinnissa. SameSite=Tiukka estää myös tämän, mutta katkaisee lailliset virrat. CSRF-tunnukset ovat edelleen suositeltu puolustus; SameSite on täydentävä kerros.

Miten CSRF eroaa XSS:stä?

XSS ruiskuttaa haitallista koodia luotettuun sivustoon ja suorittaa sen oikeuksillaan. CSRF huijaa selaimen lähettämään pyynnön luotetulle sivustolle antamatta mitään. XSS voi tehdä kaiken, mitä CSRF voi tehdä, ja enemmän. Ne ovat erilaisia hyökkäysmekanismeja.

Voinko testata CSRF:ää omassa sovelluksessani?

Kyllä. Yritä lähettää lomakkeita, joiden tunnus on poistettu tai muutettu. Jos toiminto menee läpi, sinulla on CSRF. Testaa Chromessa SameSite-valvonnalla; joissakin vanhoissa kehyksissä on CSRF-tunnuksia, joita ei varsinaisesti ole vahvistettu. Manuaalinen tarkistus on yksinkertaista.

Tarvitsevatko yksisivuiset sovellukset CSRF-suojauksen?

Jos he todentavat evästeiden avulla, kyllä. Jos he todentavat asiakaspuolelle tallennettujen siirtotietunnusten (localStorage) kautta, ne ovat vähemmän haavoittuvia CSRF:lle mutta enemmän XSS-alttiita. Molemmat hyökkäyspinnat ovat tärkeitä; Valitse todennusmekanismisi molempia ajatellen.

Onko CSRF edelleen OWASP Top 10:ssä?

Se putosi Top 10 -joukosta vuonna 2021 laajalle levinneen kehystason lieventämisen ja SameSite-evästeiden oletusasetusten vuoksi. Se on edelleen OWASP:n merkittävien haavoittuvuuksien luettelossa; esiintyvyys on laskenut, ei taustalla oleva mekanismi.

CSRF selitys: Kun verkkosivusto huijaa selaimesi toimimaan puolestasi

Cross-Site Request Forgery on haavoittuvuus, jossa haitallinen sivu pakottaa selaimesi lähettämään pyynnön sivustolle, johon olet kirjautunut sisään – käyttämällä valtuustietojasi ja suorittamalla toimia, joita et ole valtuuttanut. SameSite-evästeet ovat sulkeneet suurimman osan historiallisesta hyökkäyspinnasta, mutta taustalla olevalla luokalla on silti merkitystä aina, kun evästeet todentavat tilanmuutostoimintoja.

Artikkelin koko runko on englanniksi alla.

Cross-Site Request Forgery (CSRF, joskus kutsutaan nimellä XSRF tai "sea-surf") hyödyntää verkkosivuston luottamusta käyttäjän selaimeen. Hyökkääjä ei näe evästeitäsi, mutta selain lähettää ne automaattisesti jokaisen pyynnön yhteydessä alkuperään, johon ne kuuluvat. Jos hyökkääjä voi laukaista selaimesi tekemään pyynnön sivustolle, johon olet kirjautunut sisään, sivusto näkee todennettua pyyntöä – vaikka hyökkääjä teki sen.

Perinteinen hyökkäys

IKuvittele pankki, joka käsittelee siirrot yksinkertaisella GET-pyynnöllä: Zhttps://bank.example/transfer.to=18PL000mount.to=X8000mount? Olet kirjautunut pankkiin. Hyökkääjä lähettää sinulle sähköpostitse linkin tai isännöi sivua, jonka kuvatunniste osoittaa https://bank.example/transfer?to=Attacker&amount=10000. Selaimesi lataa kuvan; pankki näkee todennetun pyynnön istunnostasi; siirto menee läpi.

Tuo erityinen esimerkki on enimmäkseen historiallinen – pankit eivät enää käsittele siirtoja GET:n kautta – mutta malli on yleinen. Kaikki tilanmuutospyynnöt, jotka todennetaan pelkästään istuntoevästeiden avulla, ovat mahdollisesti CSRF-haavoittuvia.

`Mikä tekee CSRF:stä mahdollisen`

Kolme perustetta:

Evästeet lähetetään automaattisesti. Selain ei kysy lupaa; evästeet kuuluvat alkuperään ja kulkevat jokaisen pyynnön kanssa kyseiseen alkuperään riippumatta siitä, mistä pyyntö on aloitettu.
HTML voi käynnistää useiden lähteiden pyyntöjä. Kuvatunnisteet, lomakkeiden lähetykset, komentosarjatunnisteet ja monet muut elementit voidaan kohdistaa mihin tahansa URL-osoitteeseen. intent. Palvelin näkee todennetun pyynnön; ilman nimenomaisia CSRF-suojauksia se käsittelee toiminnon.

`Vakiopuolustus`

CSRF-tunnukset (synkronointitunnukset). Palvelin sisältää satunnaisen tunnuksen kaikissa muodoissa. Lähetysten tulee sisältää tunnus. Hyökkääjän haitallinen sivu ei pysty lukemaan tunnusta (sama alkuperäkäytäntö), joten väärennetyt pyynnöt epäonnistuvat. Nykyaikaiset verkkokehykset luovat ja vahvistavat tunnuksia automaattisesti.
SameSite-evästeet. Evästeitä, joiden merkintä on SameSite=Lax (oletus nykyaikaisissa selaimissa vuodesta 2020), ei lähetetä sivustojen välisissä pyynnöissä, paitsi ylätason navigoinnissa. SameSite=Tiukka on vieläkin tiukempi. Tämä on suurin yksittäinen muutos, joka on vähentänyt CSRF-riskiä viimeisen viiden vuoden aikana.
Alkuperä- ja viittausotsikon validointi. Palvelimet voivat tarkistaa, että Origin-otsikko vastaa odotettua alkuperää. Sivustojen välisillä pyynnöillä on eri alkuperä, mikä mahdollistaa hylkäämisen.
Double-submit cookie. Palvelin asettaa arvon sekä evästeelle että erilliselle pyyntöparametrille. todentaja tarkistaa, että ne vastaavat. Toimii ilman palvelinpuolen istunnon tilaa.
Uudelleentodennus arkaluonteisia toimia varten. Salasanan vahvistus, MFA-haaste tai tehostettu todennus arvokkaissa toimissa. Voittaa CSRF:n ja useita muita hyökkäysluokkia samanaikaisesti.

`The SameSite-evästeet vallankumoukselle`

Ennen vuotta 2020 jokainen sivustojen välinen pyyntö sisälsi kohdesivuston evästeet – mukaan lukien tilanmuutospyynnöt haitallisilta sivuilta. SameSite=Lax teki sivustojen välisistä evästeistä pikemminkin poikkeuksen kuin säännön. Tärkeimmät selaimet käyttivät Laxia oletuksena vuosina 2020–2021, ja vaikutus oli dramaattinen: useimmat satunnaiset CSRF-haavoittuvuudet muuttuivat hyödynnettämättömiksi yhdessä yössä.

Saalis: SameSite=Lax sallii edelleen evästeet ylätason sivujen uudelleenohjauksissa (full). Linkin napsautuksen käynnistämät tilanmuutostoiminnot voivat silti sisältää evästeitä. Puolustus on hyvä, mutta ei täydellinen.

SameSite=Strict estää tämän kokonaan. Kompromissi: se katkaisee kirjautumisvirrat, jotka riippuvat sivustojen välisestä navigoinnista (kertakirjautuminen, OAuthin jälkeiset uudelleenohjaukset). Useimmat suuret sivustot käyttävät Laxia oletuksena ja Strictiä vain herkimmille evästeille.

`CSRF ja APIs`

Modernit sovellusliittymät todentavat usein valtuutusotsikoiden (Bearer tokens) avulla evästeiden sijaan. CSRF ei ole käytössä, koska selain ei sisällytä automaattisesti mielivaltaisia otsikoita eri lähteiden pyyntöihin. CSRF-ongelma liittyy suurelta osin evästeiden avulla todennettuihin järjestelmiin.

Kuitenkin API:illa, jotka sekoittavat evästeitä joillekin virroille ja tunnuksia toisille, voi olla hienovaraisia CSRF-pintoja. Käytä yhtä tai toista johdonmukaisesti.

`CSRF ja CORS`

CORS (Cross-Origin Resource Sharing) määrittävät, milloin selain sallii ristiin lähtevän pyynnön lukea JavaScriptillä. CSRF koskee sitä, onko pyyntö sent ollenkaan, evästeiden kanssa. Ne liittyvät toisiinsa, mutta eroavat toisistaan:

CSRF estää haitallista sivua aiheuttamasta pyyntöä
CORS estää haitallista sivua lukemasta vastausta

A CSRF-hyökkäyksen ei tarvitse lukea vastausta – se tarvitsee vain palvelimen suorittamaan toiminto. Selain käynnistää velvollisuudentuntoisesti pyynnön ja saa vastauksen; haitallinen sivu ei ehkä näe sitä, mutta vahinko on tehty. CORS ei korjaa CSRF:ää.

`Kuuluisia CSRF-tapauksia`

Netflix-jonojen käsittely (2006). Tutkijat havaitsivat, että muotoillut IMG-tunnisteet voivat lisätä elokuvia Netflix-jonoosi ilman sinun osallistumistasi. Korjaus oli ensimmäiset laajasti käytössä olleet CSRF-tunnukset.
YouTube-tilin haltuunottovariantit 2000-luvun lopulla.
GitHub-tietovaraston poistot CSRF:n kautta012-korjauksessa2 nopeasti).
Useita WordPress-laajennuksen CSRF-haavoittuvuuksia raportoidaan vuosittain; laajennusekosysteemi tuottaa niitä edelleen suuressa mittakaavassa.

`Kehittäjille vuonna 2026`

Käytä kehystä, jossa on sisäänrakennettu CSRF-suojaus (Django, Rails, Spring, Laravel kaikilla on se)

XPlZ vaihtaminen RFRF38X pyynnöstä Jätä nämä otsikot pois

`Käyttäjille`

Et voi puolustautua suoraan CSRF:tä vastaan – se on palvelinpuolen virhe. Nykyaikaiset selaimen oletusasetukset (SameSite=Lax) auttavat huomattavasti, mutta olet riippuvainen siitä, että jokaisella kirjautumallasi sivustolla on suojaus. Pysy kirjautuneena vain niin kauan kuin tarvitset; kirjaudu ulos arkaluontoisilta tileiltä, kun niitä ei käytetä; ja luota nykyaikaisiin suuriin sivustoihin – ne kaikki ovat käsitelleet CSRF:ää uhkamalleissaan.

`Usein kysytyt kysymykset`

Tappasivatko SameSite-evästeet CSRF:n?: Vähensi sitä huomattavasti, mutta ei poistanut. SameSite=Lax (nykyaikainen oletus) sallii sivustojen väliset evästeet ylätason navigoinnissa. SameSite=Tiukka estää myös tämän, mutta katkaisee lailliset virrat. CSRF-tunnukset ovat edelleen suositeltu puolustus; SameSite on täydentävä kerros.
Miten CSRF eroaa XSS:stä?: XSS ruiskuttaa haitallista koodia luotettuun sivustoon ja suorittaa sen oikeuksillaan. CSRF huijaa selaimen lähettämään pyynnön luotetulle sivustolle antamatta mitään. XSS voi tehdä kaiken, mitä CSRF voi tehdä, ja enemmän. Ne ovat erilaisia hyökkäysmekanismeja.
Voinko testata CSRF:ää omassa sovelluksessani?: Kyllä. Yritä lähettää lomakkeita, joiden tunnus on poistettu tai muutettu. Jos toiminto menee läpi, sinulla on CSRF. Testaa Chromessa SameSite-valvonnalla; joissakin vanhoissa kehyksissä on CSRF-tunnuksia, joita ei varsinaisesti ole vahvistettu. Manuaalinen tarkistus on yksinkertaista.
Tarvitsevatko yksisivuiset sovellukset CSRF-suojauksen?: Jos he todentavat evästeiden avulla, kyllä. Jos he todentavat asiakaspuolelle tallennettujen siirtotietunnusten (localStorage) kautta, ne ovat vähemmän haavoittuvia CSRF:lle mutta enemmän XSS-alttiita. Molemmat hyökkäyspinnat ovat tärkeitä; Valitse todennusmekanismisi molempia ajatellen.
Onko CSRF edelleen OWASP Top 10:ssä?: Se putosi Top 10 -joukosta vuonna 2021 laajalle levinneen kehystason lieventämisen ja SameSite-evästeiden oletusasetusten vuoksi. Se on edelleen OWASP:n merkittävien haavoittuvuuksien luettelossa; esiintyvyys on laskenut, ei taustalla oleva mekanismi.