Skener Supabase RLS: poiščite tabele z manjkajočo ali okvarjeno varnostjo na ravni vrstic

Kaj lahko zunanje skeniranje RLS dokaže

Pasivni RLS-pregled teče proti končni točki PostgREST, ki jo Supabase izpostavlja na https://[project].supabase.co/rest/v1/. Uporablja samo objavljivi ključ anon — isti, ki ga uporablja vaš brskalnik — in poizveduje po metapodatkih seznama tabel, anonimnih branjih in anonimnih pisanjih. Nikoli se ne avtenticira kot uporabnik in nikoli ne posega po pravicah service-role. Vse, kar lahko stori, lahko stori tudi nepristen napadalec na internetu.

Od zunaj baze podatkov lahko skener z visoko zanesljivostjo potrdi naslednje:

• RLS je onemogočena na tabeli. PostgREST vrne vrstice za anonimen SELECT, kadar je RLS izklopljena ali kadar jo politika dovoljuje. Oboje je najdba.
• Anonimna vloga lahko izpiše seznam tabel. GET /rest/v1/ z anon-ključem vrne shemo OpenAPI za vsako tabelo, na kateri ima vloga anon kakršno koli pravico. UI-generirane aplikacije pogosto dodelijo USAGE na shemo in SELECT na vsako tabelo, kar razkrije celotno shemsko karto, tudi kadar RLS dejanska branja zavrača.
• Anonimna vloga lahko izvede INSERT. Poizkusni POST z uganjeno obliko stolpcev uspe, če RLS nima INSERT-politike, ki bi ga zavrnila — tudi če je SELECT zaklenjen.
• Service-role ključ je v brskalniškem snopu. Mejno z RLS: če skener najde SUPABASE_SERVICE_ROLE_KEY ali kateri koli JWT z role: service_role v JavaScript-snopu, je RLS brezpredmetna — kdor ima ta ključ, obide vsako politiko.

Česa zunanje skeniranje ne more dokazati

Bodite iskreni glede meja skenerja. Zunanji RLS-pregled ne more brati vaše tabele pg_policies, vaših datotek migracij ali natančnega predikata katere koli politike. Sklepa iz črne škatle, kar pomeni, da bo včasih sporočil najdbo, ki se izkaže za namensko javne podatke (tabela za marketinški glasilnik, javen katalog izdelkov). FixVibovo poročilo te označuje kot srednje zanesljivost, kadar skener namena ne more razločiti — preglejte ime tabele in se odločite.

Štiri oblike pokvarjene RLS, ki jih proizvedejo UI-orodja

Ko Cursor, Claude Code, Lovable ali Bolt usmerite na Supabase, se v tisočih aplikacij pojavijo isti štirje vzorci pokvarjene RLS. Vsak prestane preverjanje tipov, prevod in izdajo:

Oblika 1: RLS nikoli ni bila omogočena

Najpogostejši način odpovedi. Migracija ustvari tabelo, vendar razvijalec (ali UI-orodje) pozabi ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST veselo postreže celotno tabelo vsakemu z anon-ključem. Popravek: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE ni izbiren — brez njega lastnik tabele (in vsaka vloga z lastništvom tabele) RLS obide.

ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.[name] FORCE  ROW LEVEL SECURITY;

Oblika 2: RLS omogočena, brez politik

Bolj subtilna odpoved. RLS je omogočena, vendar politike niso napisane. Privzeto v PostgreSQL je zavrnitev, zato avtenticirani uporabniki ne vidijo ničesar — in razvijalec doda USING (true), da aplikacija deluje, kar vsem dovoli, da berejo vse. Popravek: napišite politiko, ki omejuje po auth.uid(): CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); in ustrezno politiko INSERT/UPDATE/DELETE.

CREATE POLICY "select_own"
  ON public.[name]
  FOR SELECT
  USING (auth.uid() = user_id);

Oblika 3: Politika primerja stolpec s samim seboj

A copy-paste artefact. The developer writes <code>USING (user_id = user_id)</code> — which is always true — instead of <code>USING (auth.uid() = user_id)</code>. Type-checks pass; the policy permits every row. <strong>Fix:</strong> always compare a column to a function call (<code>auth.uid()</code>, <code>auth.jwt()->>'org_id'</code>, etc.), never to itself or to a constant.

Oblika 4: Politika za SELECT, ne pa za INSERT/UPDATE

Razvijalec zaklene branja, pozabi pa pisanja. RLS-politike so per ukaz. FOR SELECT ščiti samo branja; anonimni odjemalec lahko še vedno izvede INSERT, če ga nobena politika ne zavrne. Popravek: napišite politiko za vsak ukaz ali uporabite FOR ALL z izrecnimi klavzulami USING in WITH CHECK.

Kako deluje FixVibov skener Supabase RLS

Preverjevalec baas.supabase-rls teče v treh stopnjah, vsaka z izrecno stopnjo zanesljivosti:

1. Stopnja 1 — prstni odtis. Skener preišče izdano aplikacijo, razčleni njen JavaScript-snop in iz konfiguracije izvajalnega okolja izvleče URL Supabase-projekta in anon-ključ. Brez ugibanja DNS, brez surove sile — bere to, kar bere brskalnik.
2. Stopnja 2 — odkrivanje sheme. En sam GET /rest/v1/ z anon-ključem vrne shemo OpenAPI za vsako tabelo, ki jo lahko vidi anon-vloga. Skener zabeleži imena tabel, vendar na tej stopnji ne bere podatkov vrstic.
3. Stopnja 3 — bralne in pisalne sonde. Za vsako odkrito tabelo skener izda en anonimen SELECT z limit=1. Če se vrstice vrnejo, je RLS popustljiva. Skener tam ustavi — ne našteva vrstic, ne stranično, ne spreminja podatkov. Sonde INSERT so omejene s preverjenim lastništvom domene in izrecnim soglasjem; nikoli ne tečejo proti neverificiranim ciljem.

Vsaka najdba je opremljena z natančnim URL-jem zahteve, statusom odziva, obliko odziva (samo glava) in imenom tabele. Poziv za UI-popravek na dnu najdbe je SQL-blok za kopiranje, ki ga zaženete v urejevalniku SQL Supabase.

Kaj storiti, ko skener kaj najde

Vsaka RLS-najdba je nuja izvajalnega okolja. Javne PostgREST-točke napadalci skenirajo v nekaj minutah. Postopek odpravljanja je mehanski:

1. Preglejte vsako tabelo. V urejevalniku SQL Supabase zaženite SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';. Vsaka vrstica z rowsecurity = false je problem.
2. Omogočite RLS na vsaki javni tabeli. Privzeto uporabite ENABLE ROW LEVEL SECURITY in FORCE ROW LEVEL SECURITY na vsaki ustvarjeni tabeli — naj postane predloga migracije.
3. Pišite politike ukaz za ukazom. Ne uporabljajte FOR ALL USING (true). Napišite izrecne politike za SELECT, INSERT, UPDATE, DELETE — vsako omejeno na auth.uid() ali stolpec org-id iz auth.jwt().
4. Preverite z drugim računom. Registrirajte se kot drug uporabnik, poskusite prek REST-API-ja prebrati zapise drugega uporabnika. Če je odziv 200, je politika pokvarjena.
5. Ponovno skenirajte. Po uporabi popravka zaženite nov FixVibe-pregled proti istemu URL-ju. Najdba baas.supabase-rls bi morala izginiti.

-- Audit every table for missing RLS. Run in the Supabase SQL editor.
SELECT schemaname, tablename, rowsecurity
FROM   pg_tables
WHERE  schemaname = 'public'
ORDER  BY rowsecurity, tablename;

Kako se to primerja z drugimi skenerji

Večina generičnih DAST-orodij (Burp Suite, OWASP ZAP, Nessus) ne ve, kaj je PostgREST. Preiskujejo vašo aplikacijo, ignorirajo pot /rest/v1/ in poročajo o HTML-straneh, ki jih razumejo. Snyk in Semgrep sta orodji statične analize — najdeta datoteke migracij v vašem repozitoriju z manjkajočimi RLS-klici, vendar ne moreta dokazati, da je izdana baza podatkov napačno konfigurirana. FixVibe sedi v tej vrzeli: pasiven, ozaveščen o BaaS, osredotočen na to, kaj lahko nepristen napadalec dokaže iz javnega URL-ja.

Pogosto zastavljena vprašanja

Naslednji koraki

Zaženite brezplačen FixVibe-pregled proti svojemu produkcijskemu URL-ju — preverjevalec baas.supabase-rls je omogočen v vsakem paketu, vključno z brezplačnim. Za poglobljen pregled, kaj še lahko odteka iz Supabase-projekta, glejte Supabase service-role ključ izpostavljen v JavaScriptu in Kontrolni seznam za varnost vedra Supabase Storage. Za krovni pregled vseh BaaS-ponudnikov preberite Skener napačnih konfiguracij BaaS.