CSRF ( englanniksi cross-site request forgery - "cross-site request forgery", joka tunnetaan myös nimellä XSRF) on eräänlainen hyökkäys verkkosivustojen vierailijoita vastaan , joka käyttää HTTP-protokollan puutteita . Jos uhri vierailee hyökkääjän luomalla sivustolla, uhrin puolesta lähetetään salaa pyyntö toiselle palvelimelle (esimerkiksi maksujärjestelmän palvelimelle), joka suorittaa jonkinlaisen haitallisen toiminnon (esimerkiksi siirtää rahaa hyökkääjän palvelimelle). tili). Tämän hyökkäyksen suorittamiseksi uhrin on oltava todennettu palvelimella, jolle pyyntö lähetetään, eikä tämä pyyntö saa vaatia käyttäjältä vahvistusta , jota hyökkäävä komentosarja ei voi jättää huomiotta tai väärentää .
Tämäntyyppinen hyökkäys, toisin kuin yleinen väärinkäsitys, ilmestyi melko kauan sitten: ensimmäiset teoreettiset pohdinnat ilmestyivät vuonna 1988 [1] , ja ensimmäiset haavoittuvuudet löydettiin vuonna 2000 . Ja itse termin esitteli Peter Watkins vuonna 2001 .
CSRF:n pääasiallinen käyttötarkoitus on pakottaa suorittamaan mitä tahansa toimintoa haavoittuvalla sivustolla uhrin puolesta ( salasanan vaihtaminen , salasanan palauttamisen salainen kysymys, sähköposti, järjestelmänvalvojan lisääminen jne.). On myös mahdollista hyödyntää toisella palvelimella havaittua heijastettua XSS :ää CSRF:n avulla .
Hyökkäys toteutetaan sijoittamalla web-sivulle linkki tai komentosarja, joka yrittää päästä sivustolle, jossa hyökätty käyttäjä tunnetaan (tai oletettavasti) jo todennettu. Esimerkiksi käyttäjä Alice saattaa selata foorumia, jossa toinen käyttäjä, Bob , on lähettänyt viestin. Anna Bobin luoda <img> -tunnisteen , jossa hän määritti kuvan lähteeksi URL-osoitteen , jota napsauttaessa suoritetaan Liisa pankin verkkosivuilla toiminto, esimerkiksi:
Bob: Hei Alice! Katso kuinka söpö tämä kissa on: <img src="http://bank.example.com/?account=Alice&amount=1000000&for=Bob">Jos Alicen pankki tallentaa Alicen todennustiedot evästeeseen ja jos eväste ei ole vielä vanhentunut, kun yrität ladata kuvaa , Liisa selain lähettää evästeen pyynnössä siirtää rahaa Bobin tilille, joka vahvistaa Alicen todennuksen. Siten kauppa saatetaan onnistuneesti päätökseen, vaikka sen vahvistus tapahtuu Alicesta tietämättä.
Kaikki pyynnöt, jotka muokkaavat palvelimella olevia tietoja, sekä pyynnöt, jotka palauttavat henkilökohtaisia tai muita arkaluonteisia tietoja, on suojattava.
Yksinkertaisin tapa suojautua tämäntyyppisiltä hyökkäyksiltä on vaatia verkkosivustoja vaatimaan useimpien käyttäjien toimintojen vahvistusta ja tarkistamaan HTTP_REFERER -kenttä , jos se on määritetty pyynnössä. Tämä menetelmä voi kuitenkin olla vaarallinen, eikä sitä suositella [2] .
Toinen yleinen suojausmenetelmä on mekanismi, jossa jokaiseen käyttäjäistuntoon liitetään ylimääräinen salainen yksilöllinen avain, joka on suunniteltu täyttämään pyynnöt. Salaista avainta ei tule välittää selkeästi, esimerkiksi POST - pyynnöissä avain tulee välittää pyynnön rungossa, ei sivuosoitteessa. Käyttäjän selain lähettää tämän avaimen osana kunkin pyynnön parametreja, ja palvelin tarkistaa tämän avaimen ennen minkään toimenpiteen suorittamista. Tämän mekanismin etuna Referer-tarkistukseen verrattuna on taattu suojaus CSRF-hyökkäyksiä vastaan. Haittoja ovat vaatimus mahdollisuudesta järjestää käyttäjäistuntoja, vaatimus dynaamisen HTML-koodin luomisesta sivuston sivuille sekä tarve suojautua XSS-hyökkäyksiltä ja muilta hyökkäyksiltä, jotka sallivat hyökkääjän hankkia ainutlaatuisen avaimen.
HTTP/1.1-protokollaspesifikaatio [3] määrittelee suojatut pyyntömenetelmät, kuten GET, HEAD, joiden ei pitäisi muuttaa palvelimen tietoja. Tällaisille pyynnöille ei tarvitse käyttää CSRF-suojausta niin kauan kuin palvelin on määritelmien mukainen.
Haluat ehkä pelata varman päälle ja lisätä jokaiseen pyyntöön avaimen, mutta muista, että HTTP/1.1-spesifikaatio [3] sallii rungon läsnäolon kaikissa pyynnöissä, mutta joissakin pyyntömenetelmissä (GET, HEAD, DELETE). pyynnön rungon semantiikkaa ei ole määritelty, ja se tulee jättää huomiotta. Siksi avain voidaan välittää vain itse URL-osoitteessa tai HTTP-pyynnön otsikossa. Sinun on suojattava käyttäjää jakamasta avainta vahingossa osana URL-osoitetta, esimerkiksi keskustelupalstalla, jossa avain saatetaan antaa hyökkääjän käyttöön. Sen vuoksi pyyntöjä, joissa on avain URL-osoitteessa, ei tule käyttää osoitteena, johon mennään, eli vältä pääsyä sellaiseen osoitteeseen asiakaskomentosarjan, palvelimen uudelleenohjauksen, lomaketoiminnon, sivulla olevan hyperlinkin jne. avulla piilottaaksesi URL-osoitteessa oleva avain. Niitä voidaan käyttää sisäisinä pyyntöinä vain XMLHttpRequestiä käyttävä komentosarja tai kääre, kuten AJAX .
Olennaista on, että avain (CSRF-tunnus) ei välttämättä ole tarkoitettu tiettyyn pyyntöön tai lomakkeeseen, vaan kaikkiin käyttäjän pyyntöihin yleensä. Siksi riittää, että CSRF-tunnus vuotaa URL-osoitteesta, joka suorittaa yksinkertaisen toiminnon tai ei toimi ollenkaan, jotta mikä tahansa toiminto, ei vain se, johon nyt tunnettu URL-osoite liittyy, menettää suojan pyyntöjen väärentämistä vastaan.
Edellisestä mekanismista on jäykempi versio, jossa jokaiseen toimintoon liittyy ainutlaatuinen kertakäyttöinen avain. Tämä menetelmä on vaikeampi toteuttaa ja vaatii resursseja. Menetelmää käyttävät jotkin sivustot ja portaalit, kuten Livejournal , Rambler jne. Vuoden 2016 osalta ei ollut tietoa jäykemmmän vaihtoehdon eduista verrattuna vaihtoehtoon, joka käyttää yhtä salaista avainta jokaisessa istunnossa [4] .