Supabase baze pojedinih aplikacija ostale su dostupne javnosti zbog pogrešnih podešavanja i nebezbednog načina na koji su klijentske aplikacije pristupale podacima. Problem nije dokaz da je sama platforma automatski ranjiva. Supabase je napravljen tako da određeni javni ključ može biti ugrađen u aplikaciju, ali prava zaštita mora da postoji u pravilima pristupa, posebno kroz Row Level Security i pravilno definisane politike.
Supabase baze i javni ključevi
Frontend aplikacija mora da zna adresu projekta i takozvani anon ključ da bi komunicirala sa dozvoljenim servisima. Taj ključ se ne smatra potpunom tajnom na isti način kao administratorski service role ključ. Greška nastaje kada tim pretpostavi da skrivanje vrednosti u JavaScript paketu sprečava pristup, a tabela u bazi nema politiku koja ograničava šta anonimni ili prijavljeni korisnik sme da čita i menja.
Napadaču tada nije potreban složen proboj. Dovoljno je da pregleda mrežne zahteve aplikacije, identifikuje projekat i proveri koje tabele ili skladišni kontejneri odgovaraju bez pravilne autorizacije. Ako je dozvoljen širok upit, mogu biti izloženi e-mailovi, profili, interne beleške, tokeni ili drugi podaci koje programer nije nameravao da objavi.
Row Level Security nije opciona dekoracija
RLS primenjuje pravila na redove tabele. Umesto da prijavljen korisnik automatski vidi sve, politika može da dozvoli samo redove čiji owner_id odgovara identitetu iz sesije. Posebne politike se pišu za čitanje, unos, izmenu i brisanje. Uključivanje RLS bez odgovarajućih pravila može da blokira aplikaciju, ali potpuno isključivanje radi bržeg razvoja ostavlja mnogo veći rizik.
Administratorski service role ključ zaobilazi RLS i nikada ne sme biti u mobilnoj aplikaciji, JavaScript kodu, javnom repozitorijumu ili snimku ekrana. Koristi se samo na pouzdanom serveru i mora imati kontrolisan pristup. Ako je takav ključ procureo, samo popravljanje politike nije dovoljno: ključ treba rotirati, pregledati logove i utvrditi koje operacije su obavljene.
Kontrolna lista za programere
- Uključite RLS na svakoj tabeli koja sadrži korisničke ili interne podatke.
- Napišite odvojene politike za SELECT, INSERT, UPDATE i DELETE i testirajte ih sa različitim nalozima.
- Proverite Storage bucket pravila; privatna tabela ne štiti automatski javno skladište fajlova.
- Držite service role i druge tajne samo na serverskoj strani i rotirajte ih posle svakog curenja.
- U CI procesu dodajte test koji pokušava pristup tuđem zapisu i anonimni izvoz podataka.
Test ne treba da se svodi na proveru da aplikacija radi sa administratorskim nalogom. Potrebni su anonimni korisnik, običan korisnik A, običan korisnik B i servisni proces. Svaki pokušaj pristupa tuđem resursu mora završiti odbijanjem. Posebno treba proveriti API prikaze, funkcije, rezervne kopije, privremene tabele i linkove za javno deljenje.
Ne propustite ovo
Šta uraditi ako su podaci već bili javni
Prvo ograničite pristup bez uništavanja dokaza. Sačuvajte logove, identifikujte period izloženosti i vrste podataka, zatim rotirajte ključeve, tokene i lozinke koje mogu biti zloupotrebljene. Ne pretpostavljajte da odsustvo velikog preuzimanja u jednom logu znači da podaci nisu kopirani. Potrebna je procena obaveštavanja korisnika i nadležnih organa u skladu sa vrstom podataka i jurisdikcijom.
Naš tekst o zlonamernom JavaScriptu u online prodavnicama pokazuje zašto tajne u klijentskom kodu i kompromitovan frontend zahtevaju širu istragu. Kod Supabase aplikacije treba pregledati i istoriju repozitorijuma, build logove i prethodne verzije aplikacije, jer uklanjanje ključa iz najnovijeg commita ne briše staru kopiju.
Bezbedan razvojni proces
Razvojna i produkciona baza treba da budu odvojene, sa sintetičkim podacima u testu. Migracije koje menjaju politike moraju kroz pregled koda, a dashboard treba da upozori na tabele bez RLS-a. Programerima je korisno dati najmanja potrebna ovlašćenja i beležiti administratorske promene. Bezbednost ne može da zavisi od toga da jedan član tima pamti sve ručne korake.
Zaključak
Supabase može biti bezbedna osnova, ali javni frontend ključ ne zamenjuje autorizaciju. Timovi moraju da uključe i testiraju RLS, zaštite service role ključ i provere skladište fajlova. Ako je baza bila dostupna, odgovor treba da uključi forenziku, rotaciju i procenu curenja, a ne samo brzo zatvaranje jedne tabele. Dokumentujte ko je odobrio svaku promenu i ponovite testove iz čiste, anonimne sesije pre vraćanja servisa u normalan rad.
