Ylläpidon aliverkkotunnus ei estä CSRF:ää: neljä tarkistusta ennen julkaisua

Ylläpitoliittymän siirtäminen osoitteeseen admin.example.com on todellinen parannus: se pitää ylläpitoevästeet poissa julkisilta sivuilta, antaa kahdelle sovellukselle erilliset välimuistit ja mahdollistaa tiukemman verkkokäytännön kohdistamisen yhteen isäntänimeen. Se ei kuitenkaan ole CSRF-suoja, eikä tee julkisen sivuston koodista turvallista pitää auki kirjautuneelle ylläpitäjälle. Erottelu muuttaa sitä, mitä selain pitää rajana, ei sitä, mitä palvelin tarkistaa, joten tee nämä neljä tarkistusta ennen kuin sanot sen olevan valmis.

Lue origin ja sivusto kahtena eri sanana

Origin on skeema, isäntä ja portti, joten https://www.example.com ja https://admin.example.com ovat eri origineja. Sivusto SameSiten mielessä on skeema plus rekisteröitävä verkkotunnus, joten samat kaksi isäntänimeä ovat yleensä sama sivusto. Tämä ero on koko ansa: SameSite-attribuutti ei auta sisaraliverkkotunnusten välillä, koska selain ei pidä pyyntöä lainkaan sivustojen välisenä. Ohjaa ylläpitoliittymä todella toiseen rekisteröitävään verkkotunnukseen, kuten admin-example.net, ja pyynnöstä tulee todella sivustojen välinen, ja siinä SameSite=Lax tai Strict alkaa tehdä työtä, johon voi luottaa.

Testaa sitä selaimessa sen sijaan että päättelet siitä.

Lataa julkinen sivusto, avaa kehittäjätyökalut ja katso, mitkä evästeet selain liittää ylläpitoisäntään osoitettuun pyyntöön. Jos evästeellä ei ole Domain-attribuuttia, se on vain isännän ja pysyy omalla nimellään; jos se kantaa Domain=example.com, se matkustaa jokaiselle sisarelle, eikä uusi aliverkkotunnus antanut sinulle mitään sen evästeen osalta.

Erota vastauksen lukeminen pyynnön lähettämisestä

Saman originin käytäntö rajoittaa vastausten lukemista originien välillä. Se ei estä pyynnön lähettämistä eikä estä lomaketta kuljettamasta tunnistetietoja, jotka selaimella jo on. Yksinkertainen pyyntö, jossa on lomakkeen sisältötyyppi tai tavallinen GET, toimitetaan ilman esitarkistusta; CORS päättää sitten, saako kutsuva skripti lukea vastauksen. CSRF elää kokonaan lähettämisen puolella.

Siksi palvelin tarvitsee eksplisiittisen tarkistuksen tilaa muuttaville toiminnoille. Istuntoon sidottu synkronointitoken tai palvelimella verrattava kaksoislähetyksen eväste kattaa tapauksen; Origin- tai Referer-vertailu kannattaa lisätä toiseksi portiksi mutta ei ainoaksi, koska jokainen pyyntö ei kanna otsaketta eikä jokainen välityspalvelin säilytä sitä. OWASP:n CSRF:n estämisen ohje pitää SameSitea yhtenä kerroksena useiden joukossa juuri tästä syystä.

Päätä, mitä verkkoportti todella todistaa

VPN-poistumien sallittujen luettelo ylläpitoisännän edessä on hyvä valvonta ja heikko identiteettiväite. Se todistaa, että pyyntö tuli osoitteesta, jonka VPN antaa, jota kaikki kyseisellä poistumalla voivat jakaa, eikä kerro mitään siitä, kuka henkilö tai mikä laite on sen takana. Kohtele sitä sisäänkäyntisuodattimena, älä todentamisena.

Pidä se riippumattomana pyyntötason tarkistuksista. Jos luettelo on ainoa asia hyökkääjän ja tilaa muuttavan päätepisteen välillä, yksi väärin määritetty reitti, yksi split-tunnel-asiakas tai yksi lainattu kannettava poistaa valvonnan kokonaan.

Kirjaa myös hylkäykset odotettujen alueiden ulkopuolelta. Niiden ryöppy on hyödyllisin signaali siitä, että joku koettelee juuri rakentamaasi rajaa, ja hiljaisuus on signaali siitä, ettei suodatinta tavoiteta lainkaan.

Pidä evästeet, kirjautuminen ja valtuutus eksplisiittisinä

Evästeen laajuus ratkaisee suurimman osan tuloksesta. Ylätason verkkotunnuksen eväste lähetetään ylläpitoisännälle, joten julkisen sivuston skripti-injektio voi toimia ylläpitäjän istunnolla; vain isännän eväste ei voi. Suosi vain isännän muotoa, lisää Secure-attribuutti ja käytä __Host--etuliitettä siellä, missä alusta tukee sitä, koska etuliite vaatii Securen, Path=/-polun ja ilman Domain-attribuuttia. Lue vastauksen otsake, älä evästepurkkia: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, ilman Domain-attribuuttia. Selain hylkää __Host--evästeen, jossa on Domain, joten sisarisännöillä yhä näkyvä eväste on todiste siitä, ettei etuliitettä koskaan sovellettu.

Pidä sitten valtuutus palvelimella, pyyntöä kohti, jokaisessa ylläpitopäätepisteessä, ei vain kirjautumisessa. Sallitusta verkosta tuleva pyyntö on yhä todennettava ja valtuutettava pyytämäänsä toimintoon; isäntänimi ei ole toimija. Jos julkinen ja ylläpitosovellus jakavat kirjautumisvirtauksen tai istuntosäilön, kirjoita se suhde muistiin, koska se on lyhin polku julkisen sivuston virheestä ylläpitotoimeen.

Tarkista raja uudelleen erottelun jälkeen

Aja negatiiviset testit, älä vain onnellista polkua: ilman tokenia oleva sivustojen välinen lomake on hylättävä, toisen istunnon token on hylättävä eikä minkään GETin pidä muuttaa tilaa. Tarkista evästeiden attribuutit kehittäjätyökaluissa, varmista että Origin-tarkistus laukeaa yhteensopimattomassa pyynnössä ja kokeile ylläpitoisäntää VPN-alueen ulkopuolelta nähdäksesi suodattimen toimivan.

Mikään tästä ei poista XSS-virhettä itse ylläpitosovelluksen sisällä. Erillinen isäntänimi on selainpuolen eristysraja, jolla on todellinen arvo, eikä se korvaa turvattoman koodin suorittamisen estämistä tai palvelinpuolen pyyntöjen suojausta. Erottelun jälkeen lista on lyhyempi kuin miltä näyttää: erillinen origin, vain isännän evästeet, token joka muutoksessa, sisäänkäyntisuodatin, johon et luota identiteettinä, ja pyyntökohtaisesti päätetty valtuutus.