Supabase RLS: käsin tehtävä auditointi vai skannaus?

Rivitason suojaus on raja Supabase-projektin, joka suojaa tietojaan, ja sellaisen projektin välillä, joka paljastaa ne hiljaa. Kun RLS on määritetty hyvin, tietokanta pakottaa käyttöoikeussääntöjä rivitasolla RLS:n alaisten roolien osalta. Etuoikeutetut roolit, mukaan lukien palvelurooli, voivat ohittaa nämä säännöt. Kun se on määritetty huonosti, taulukot näyttävät suojatuilta, kun taas käytännöt päästävät läpi enemmän kuin tarkoitit.

Tässä artikkelissa verrataan kahta tapaa suorittaa Supabase RLS -suojaustarkistus: käytäntöjen tarkistaminen käsin ja automaattisen RLS-tarkastuksen suorittaminen. Molemmilla on paikka. Kun tiedät, missä kukin hajoaa, voit varmistaa, että tietokannan käyttökäytännöt toimivat tarkoitetulla tavalla.

RLS on Postgres-ominaisuus, jonka Supabase paljastaa taulukkoa kohti. Kun taulukko on otettu käyttöön, se estää rivien pääsyn rooleihin, joihin sovelletaan RLS, ellei käytäntö salli sitä. taulukoiden omistajat ja roolit, joilla on ohitusoikeudet, ovat poikkeuksia. Käytännöt arvioidaan nykyisen käyttäjän, hänen vaatimustensa ja suoritettavan kyselyn perusteella. The auth.uid() toiminto on yleensä ankkuri: politiikka, kuten using (auth.uid() = user_id) rajoittaa pääsyä sisäänkirjautuneen käyttäjän omiin tietokantariveihin.

Malli on siisti. Epäonnistumiset eivät ole, koska ne harvoin näyttävät epäonnistumisilta.

Muutamat kuviot kattavat useimmat RLS-ongelmat:

• RLS käytössä joissakin pöydissä, ei kaikissa. Uusi taulukko, joka on lisätty julkaisun jälkeen tai luotu siirrolla, voidaan toimittaa RLS pois päältä. Jokainen rivi on sitten kaikkien taulukkokäyttöisten roolien luettavissa.

• Politiikka, joka on laajempi kuin se lukee. using (true) valitussa käytännössä tarkoittaa, että jokainen rivi on näkyvissä. Se on helppo lisätä kehityksen aikana virheenkorjausta varten ja unohtaa poistaa.

• Palvelurooli otettiin vastaan kaikkialla. Palvelinpuolen koodi, joka käyttää palvelurooliavainta, ohittaa RLS:n kokonaan. Jos käyttäjille suunnatut pyynnöt suoritetaan kyseisen avaimen kautta, käytäntöjä ei koskaan sovelleta.

• Käytännöt, jotka tarkistavat väärän sarakkeen. auth.uid() = id pöydällä missä id on rivin ensisijainen avain, ei omistaja, ei koskaan vastaa tarkoitusta. Käytäntö on olemassa, se palauttaa virheen tai tyhjän joukon, ja pinta toimii edelleen.

• Tietokannan päivitykset ja poistot ilman asianmukaisia käyttöoikeuksia. Kehittäjät suojaavat usein valinnan perusteellisesti ja jättävät kirjoituskäytännöt löysäksi. Lukutarkistuksen läpäiseminen ei kerro mitään siitä, kuka voi muokata riviä seuraavaksi.

Mikään näistä ei kerro itsestään. Jokainen pitää sovelluksen toiminnassa, minkä vuoksi ne säilyvät tuotantoon asti.

Manuaalinen tarkastus on suora eikä vaadi uusia työkaluja. Työskentelet itse käytännöt läpi taulukko taulukolta.

Aloita luetteloimalla jokainen taulukko ja varmistamalla, että RLS on käytössä jokaisessa. Luettele sitten kunkin taulukon käytännöt ja yhdistä ne aiottuihin käyttöoikeuksiin: kenen pitäisi lukea, kenen tulee kirjoittaa ja kenen ei saa koskaan koskea siihen. Lue jokainen käytäntölauseke verrattavaan sarakkeeseen. Varmista, että valinnalla, lisäämällä, päivittämällä ja poistamalla kullakin on käytäntö, joka vastaa aiottua roolia.

Tarkista seuraavaksi koodipolku. Selvitä, mitä avainta sovelluksesi todella käyttää käyttäjille suunnatuissa pyynnöissä ja suoritetaanko jokin niistä palveluroolin kautta. Kirjoita sitten testikyselyitä eri käyttäjillä ja varmista, että tulokset vastaavat odotuksia: käyttäjän tulee lukea omat rivinsä eikä kenenkään muun, eikä hänen pitäisi pystyä päivittämään riviä, jota hän ei omista.

Manuaalinen tarkistus kannattaa tehdä, ja se saa paljon kiinni. Siinä on myös ennustettavia kuolleita kulmia.

• Se testaa mitä muistat testata. Jos et ajattele poistamista toisena käyttäjänä, saatat unohtaa liian laajan poistokäytännön. Kun RLS on käytössä, soveltuva poistokäytäntö tarkoittaa, että poistaminen on estetty.

• Se vanhenee. Käytännöt muuttuvat, kun ominaisuuksia lisätään. Viimeisellä neljänneksellä tehty perusteellinen katsaus ei kerro mitään viime viikolla lisäämästäsi taulukosta.

• Se riippuu samasta henkilöstä, joka on määrittänyt käytännöt. Käytännön kirjoittanut rakentaja huomaa vähiten oman oletuksensa.

• Se vaatii kirjattuja todisteita. "Tarkastin sen ja se näytti oikealta" ei jätä jälkeen mitään: ei todisteita, ei kattavuutta, ei artefakteja, jotka voit skannata uudelleen myöhemmin.

Manuaalinen auditointi vastaa kysymykseen "vastaako tämä järjestelmän henkistä malliani?" Se ei yksinään todista, mitä tietokanta todella palauttaa.

Automaattinen Supabase RLS -turvatarkastus toimii toisesta suunnasta. Se harjoittelee projektia hyökkääjän tai väärin määritettyjen asiakkaiden tapaan ja raportoi, mitä tietokerros todella sallii.

Tämä muutos on tärkeä kolmesta syystä. Ensinnäkin se skaalaa muistin ohi: skannaus toistaa tarkistukset määritetyllä alueella käytettävissä olevissa taulukoissa ja päätepisteissä. Ulkoinen tarkistus ei voi tarkastaa jokaista käytäntöä ilman sopivaa pääsyä. Toiseksi se tuottaa todisteita, joiden perusteella voit toimia: löydös nimeää taulukon, käytännön tilan ja ehdon, joka teki sen saavutettaviksi, jotta tiedät mitä muuttaa ja miksi. Kolmanneksi se on toistettavissa. Uudelleen suoritettava tarkistus muuttaa kertatarkistuksen jatkuvaksi todennukseksi.

VICE skannaa verkkosovelluksia ja Supabase/RLS-kokoonpanoja ja raportoi sitten löydöksistä ja niiden taustalla olevista todisteista ja korjausohjeista. Voit merkitä korjauksen ja pyytää uudelleentarkistusta, mutta vain vastaava uudelleenskannaus vahvistaa, että ongelma on ratkaistu: korjaus tarkistetaan samaa laajuutta vastaan, eikä sitä ole oletettu muokkauksesta. Suunnitellut tarkistukset ja hälytykset tukevat jatkuvaa seurantaa, joten ensi kuussa lisättävä taulukko ei hiljaa lisää aukkoa.

Työnjako on suoraviivaista. Suorita automaattinen tarkistus selvittääksesi, mitä manuaalisesta tarkistuksestasi jäi huomaamatta, ja käytä sitten manuaalista passia vahvistaaksesi jokaisen tarkistusmerkinnän taustalla olevan tarkoituksen. Automaatio kertoo, mitä tietokanta sallii; päätät, oliko lupa tahallinen.

Minkä tahansa skannauksen pisteet kuvaavat testattua laajuutta, eivät takaa, että projekti on täysin suojattu. Käsittele sitä signaalina siitä, mistä etsiä, älä todistuksena.

Jos otat käyttöön Supabase:llä rakennettua tuotetta, etkä ole koskaan tarkastanut käytäntöjäsi, rehellinen vastaus on molemmat kunnossa. Aloita automaattisella RLS-tarkistuksella, jotta sinulla on ajantasainen, näyttöön perustuva kuva siitä, mitä taulukot sallivat. Kävele sitten löydöksiä käsin, vahvista kunkin käytännön tarkoitus ja korjaa ne, jotka ajautuivat. Aseta automaattinen tarkistus aikatauluun, jotta uudet taulukot ja uudet käytännöt saavat saman tarkastelun kuin alkuperäiset.

Jommankumman lähestymistavan ohittaminen voi jättää tietokannan käyttökäytännön, joka näyttää suojaavan tietoja, mutta sallii silti luvattoman käytön.

Aloita ilmainen skannaus osoitteessa vice-platform.com tarkistaaksesi julkisen verkkosivustosi ennen rekisteröitymistä. Erikoistunut Supabase-skannaus vaatii vahvistetun verkkotunnuksen ja maksetun tilauksen tai ostetun saldon; sen kattavuus riippuu määritetystä pääsystä.