Keskustelu: Nettisivujen teko: CSRF:n torjuminen Referer-otsikon tarkistuksella

Eikö pelkkä Referer-otsikon tarkistus riittäisi CSRF-hyökkäyksen torjumiseen, jos pyyntö hylätään myös silloin, kun kyseinen otsikko puuttuu tai sen arvo on tyhjä?

Periaatteessa selainten ei ole pakko lähettää kyseistä otsikkoa, jolloin lomake ei toimisi osalla käyttäjistä, mutta käytännössä tällainen lienee harvinaista.

(Tulevaisuudessa, kun kaikki selaimet tukevat evästeiden SameSite-määritettä, hyökkäyksen voi torjua pelkällä evästeellä, ilman piilokenttää tms.)

Ei riitä. Kaikki datamuokkaukset tulisi myös olla PUT/POST/PATCH/DELETE -tyyppisiä.

Oletetaan että sallit vaikka käyttäjän asettaa itselleen avatariksi urlin kuvatiedostoon, joka mäpätään img src -attribuuttiin koodissasi. Jos käyttäjä asettaa avatarin urliksi http://domain.org/change_password?password­=123456&confirmation=123456 (joka on salasanan vaihdon osoite palvelussa), tulee myös huolehtia että vaihto tehdään esimerkiksi ainoastaan POST sallimalla. Mikäli kutsu sallii GET:n, on paskamyrsky valmis kun jokaisen foorumia selaavan salasana muuttuu aina, kun hackermanin avatar yritetään ladata foorumilla.

antiforgery tokenit tulee taasen lisätä, jotta ulkoinen palvelu ei pysty lähettämään lomakedataapalveluun, mikäli käyttäjä ohjataan "OLET VOITTANUT IPHONEN! -huijaussivustolle". ulkoisessa palvelussa eivät näy csrf token (eikä sessiotoken) koska nämä on rajoitettu same origin policyllä (domain rajoite), eikä näin ollen postaukset onnistu valheellisella datalla alkuperäiseen palveluun takaisin. jos csrf suojausta ei ole lomakkeella, voidaan käyttäjä ohjata valheellisesti postaamaan takaisin palveluun josta huijaussivustolle saavuttiin, koska autentikointikeksi on voimassa.

Tästä päästään oivana aasinsiltana XSS -puoleen, jossa tätä samaa voidaan kiertää esimerkiksi kuvan sisälle tehtyyn mekanismiin (jos palvelu sallii kuvien uppimisen, tai kuvien näyttämisen oman domainin ulkopuolelta), joka pääsee selaimessa ladattuna kiinni document.cookiesiin. Tästä syytä on tärkeää, että csrf ja sessiokeksit ovat httpOnly, eivätkä näin ollen javascriptistä käsin käsiteltävissä kun kuva ladataan toisen käyttäjän toimesta foorumilla. jos keksit eivät ole httpOnly, pystyy kuvan scriptissä vaikka lähettämään ko. keksien datat haluttuun kohteeseen, ja näin ollen kaappaamaan session.

Refererin tosiaan voi vaihtaa, tässä pari esimerkkiä:

Esimerkki curlilla (curl --referer nönnöö osoite)
https://imagebin.ca/v/3wF3opPNZGic

Esimerkki suoraan chromen developer toolsissa:

//Ajoin consolessa suoraan seuraavan:
$.get("https://www.ohjelmointiputka.net/keskustelu?test=moro")

Joka palautti:
https://imagebin.ca/v/3wF4jeTcZoP9

Lisäys: Tämä viesti lähetettiin postmanilla, sessiokaappauksella ja forgerytokenit kopioimalla.

Ylläolevasta ulkoista postauksesta kuva tässä ("lisäys" -kohta):
https://imagebin.ca/v/3wF8q6r2u92g

Soo soo, läpi meni vaikka olin asettanut referreriksi www.yle.net. En myöskään kaapannut sessiota mitenkään hackerman -tyyppisesti, kopsasin vain omat tiedot. mutta saman sessiokaappauksen voisi tehdä xss scriptaamalla, jos sivustoa ei olisi tältä suojattu.

groovyb kirjoitti:

Ei riitä. Kaikki datamuokkaukset tulisi myös olla PUT/POST/PATCH/DELETE -tyyppisiä.

Totta. Unohdin mainita, että sallin lomakkeissa vain POST-pyynnöt.

groovyb kirjoitti:

Refererin tosiaan voi vaihtaa, tässä pari esimerkkiä:

Toki voi, mutta selaimen APIt eivät salli sitä, jolloin hyökkäystä ei voi tehdä toiselta sivustolta.

Sallin siis vain POST-pyynnöt, joiden Referer-otsikossa on oikea domain. Jos selain lähettää Origin-otsikon, vaadin lisäksi, että siinäkin on oikea domain.

toiselta sivustolta voi tehdä, jos vaan ajetaan frontin ajax -kutsun sijaan kutsu backendissä (jos oletetaan että sessiotietoa ei tarvita). Ei ole mikään olettamus, että kutsu tapahtuu ajaxilla tai http requestina selaimen kautta. Koska selaimet estää refererin vaihdon, luonnollisesti tekisin tämän backendissä, enkä edes vaivautuisi frontin päässä. Kyllä ne csrf tokenit siellä lomakkeilla kannattaa olla, niin staattiset formisisällöt ei painu läpi.

Totta! Palautan tuon eväste–piilokenttä-ratkaisun sivustolleni. Jätän kuitenkin myös Referer- ja Origin-tarkistukset paikoilleen, koska OWASP suosittelee molempia.

Onneksi joskus tulevaisuudessa on helpompaa, kun tarvitsee vain SameSite-evästeen eikä sen lisäksi piilokenttää. Sitä odotellessa…

Eipä tuo mihinkään poistu, jos käytössä on esimerkiksi subdomainissa kuuntelevia apeja eikä vain perinteinen backend - frontend softa. softarakenteita kun on niin monia, ei kaikki softat pyöri yhden osoitteen päällä.

groovyb kirjoitti:

Eipä tuo mihinkään poistu, jos käytössä on esimerkiksi subdomainissa – –

Hyvä pointti tosiaan. Kuitenkin monissa tapauksissa SameSite-eväste mahdollistaa yksinkertaisemman CSRF-suojauksen – ei toki aina.