Supabase RLS: audyt ręczny czy skanowanie?

Row Level Security to granica pomiędzy projektem Supabase, który chroni dane, a projektem, który po cichu je ujawnia. Gdy RLS jest dobrze skonfigurowany, Twoja baza danych wymusza reguły dostępu na poziomie wiersza, dla ról podlegających RLS. Role uprzywilejowane, w tym rola usługi, mogą ominąć te reguły. Gdy jest źle skonfigurowany, tabele wyglądają na chronione, a zasady przepuszczają więcej, niż zamierzałeś.

W tym artykule porównano dwa sposoby przeprowadzenia kontroli bezpieczeństwa Supabase RLS: ręczną weryfikację zasad i uruchomienie automatycznego audytu RLS. Obydwoje mają swoje miejsce. Wiedza o tym, gdzie następuje awaria każdego z nich, pozwala sprawdzić, czy zasady dostępu do bazy danych działają zgodnie z oczekiwaniami.

RLS to funkcja Postgres, którą Supabase udostępnia dla każdej tabeli. Po włączeniu tabela odmawia dostępu do wierszy rolom podlegającym RLS, chyba że zasady na to pozwalają; wyjątkami są właściciele tabel i role z uprawnieniami pomijania. Zasady są oceniane pod kątem bieżącego użytkownika, jego oświadczeń i uruchamianego zapytania. The auth.uid() Funkcja jest zwykle kotwicą: polityką typu using (auth.uid() = user_id) ogranicza dostęp do własnych wierszy bazy danych zalogowanego użytkownika.

Model jest czysty. Awarie nimi nie są, ponieważ rzadko wyglądają na awarie.

Kilka wzorców odpowiada za większość problemów RLS:

• RLS włączono w niektórych tabelach, ale nie we wszystkich. Nowy stół dodany po uruchomieniu lub utworzony w wyniku migracji może być dostarczony z wyłączonym RLS. Każdy wiersz jest następnie czytelny dla dowolnej roli z dostępem do tabeli.

• Polityka, która jest szersza, niż się wydaje. using (true) w przypadku wybranej zasady oznacza, że każdy wiersz jest widoczny. Łatwo jest dodać go podczas programowania w celu debugowania i zapomnieć go usunąć.

• Wszędzie przyjmowano rolę usługową. Kod po stronie serwera korzystający z klucza roli usługi całkowicie omija RLS. Jeśli żądania kierowane do użytkownika przebiegają przez ten klucz, zasady nigdy nie mają zastosowania.

• Zasady sprawdzające niewłaściwą kolumnę. auth.uid() = id na stole, gdzie id jest kluczem podstawowym wiersza, a nie właścicielem, nigdy nie będzie zgodny z intencją. Zasada istnieje, zwraca błąd lub pusty zbiór, a powierzchnia nadal się zachowuje.

• Aktualizacje i usunięcia baz danych bez odpowiedniej kontroli dostępu. Programiści często dokładnie zabezpieczają wybór i pozostawiają luźne zasady zapisu. Przekazanie kontroli odczytu nie mówi nic o tym, kto może następnie zmodyfikować wiersz.

Żaden z nich nie ogłasza się sam. Każdy z nich zapewnia działanie aplikacji i właśnie dlatego przetrwały do ​​produkcji.

Audyt ręczny jest bezpośredni i nie wymaga nowych narzędzi. Opracowujesz same zasady, tabela po tabeli.

Zacznij od wylistowania wszystkich tabel i sprawdzenia, czy w każdej z nich jest włączone RLS. Następnie dla każdej tabeli wylicz zasady i przyporządkuj je do zamierzonego dostępu: kto powinien czytać, kto pisać i kto nigdy nie powinien jej dotykać. Przeczytaj każde wyrażenie zasad w odniesieniu do kolumny, którą porównuje. Upewnij się, że każda opcja wyboru, wstawienia, zaktualizowania i usunięcia ma zasady odpowiadające zamierzonej roli.

Następnie sprawdź ścieżkę kodu. Określ, którego klucza faktycznie używa Twoja aplikacja do obsługi żądań skierowanych do użytkownika i czy którykolwiek z nich przechodzi przez rolę usługi. Następnie napisz zapytania testowe jako różni użytkownicy i potwierdź, że wyniki odpowiadają oczekiwaniom: użytkownik powinien czytać swoje własne wiersze, a nie nikogo innego, i nie powinien mieć możliwości aktualizowania wiersza, którego nie jest właścicielem.

Ręczny przegląd warto zrobić, a wyłapuje sporo. Ma również przewidywalne martwe punkty.

• Testuje to, o czym pamiętasz, aby przetestować. Jeśli nie pomyślisz o usunięciu jako drugi użytkownik, możesz przegapić zbyt szerokie zasady usuwania. Po włączeniu RLS brak odpowiednich zasad usuwania oznacza odmowę usunięcia.

• Starzeje się. Zasady zmieniają się wraz z dodawaniem nowych funkcji. Dokładna recenzja przeprowadzona w zeszłym kwartale nie mówi nic o stole dodanym w zeszłym tygodniu.

• Zależy to od tej samej osoby, która skonfigurowała zasady. Budowniczy, który napisał polisę, najmniej prawdopodobne jest, że dostrzeże własne założenia.

• Potrzebuje zarejestrowanych dowodów. „Przejrzałem to i wyglądało dobrze” nie pozostawia po sobie żadnych śladów: żadnych dowodów, żadnego lunety, żadnych artefaktów, które można później ponownie przeskanować.

Audyt ręczny odpowiada na pytanie „czy pasuje to do mojego mentalnego modelu systemu?” Samo w sobie nie dowodzi, co faktycznie zwróci baza danych.

Zautomatyzowana kontrola bezpieczeństwa Supabase RLS działa z drugiej strony. Ćwiczy projekt w sposób, w jaki zrobiłby to atakujący lub źle skonfigurowany klient, i raportuje, na co faktycznie pozwala warstwa danych.

Ta zmiana ma znaczenie z trzech powodów. Po pierwsze, skaluje pamięć: skanowanie powtarza sprawdzanie tabel i punktów końcowych dostępnych w skonfigurowanym zakresie. Zewnętrzne skanowanie nie jest w stanie sprawdzić każdej polityki bez odpowiedniego dostępu. Po drugie, dostarcza dowodów, na podstawie których możesz podjąć działania: wynik podaje nazwę tabeli, stan polityki i warunek, dzięki któremu stał się osiągalny, dzięki czemu wiesz, co i dlaczego zmienić. Po trzecie, jest powtarzalny. Kontrola, którą możesz przeprowadzić ponownie, zmienia jednorazową weryfikację w weryfikację ciągłą.

VICE skanuje aplikacje internetowe i konfiguracje Supabase/RLS, a następnie raportuje ustalenia wraz z dowodami za nimi i wskazówkami dotyczącymi poprawek, na których można bazować. Możesz oznaczyć poprawkę i poprosić o ponowne sprawdzenie, ale tylko porównywalne ponowne skanowanie potwierdzi, że problem został rozwiązany: poprawka jest weryfikowana w tym samym zakresie, a nie zakładana na podstawie edycji. Zaplanowane skany i alerty wspierają ciągłe monitorowanie, więc tabela dodana w przyszłym miesiącu nie przywróci po cichu luki.

Podział pracy jest prosty. Uruchom automatyczne sprawdzanie, aby dowiedzieć się, co przeoczyłeś podczas ręcznej weryfikacji, a następnie użyj ręcznego przejścia, aby potwierdzić intencje stojące za każdą zasadą oznaczoną przez skanowanie. Automatyzacja mówi Ci, na co pozwala baza danych; Ty decydujesz, czy to pozwolenie było zamierzone.

Wynik dowolnego skanowania opisuje testowany zakres, a nie gwarancję, że projekt jest w pełni bezpieczny. Traktuj to jako sygnał, gdzie szukać, a nie certyfikat.

Jeśli wdrażasz produkt zbudowany na bazie Supabase i nigdy nie sprawdzałeś swoich zasad, szczera odpowiedź brzmi: jedno i drugie jest w porządku. Zacznij od automatycznej kontroli RLS, aby uzyskać aktualny, poparty dowodami obraz tego, na co pozwalają Twoje tabele. Następnie ręcznie przeanalizuj ustalenia, potwierdź cel każdej zasady i napraw te, które uległy zmianie. Zaplanuj automatyczną kontrolę, aby nowe tabele i nowe zasady podlegały takiej samej kontroli, jak oryginalne.

Pominięcie któregokolwiek podejścia może spowodować pozostawienie zasad dostępu do bazy danych, które pozornie chronią dane, ale nadal umożliwiają nieautoryzowany dostęp.

Rozpocznij bezpłatne skanowanie na stronie vice-platform.com, aby sprawdzić swoją publiczną witrynę internetową przed zarejestrowaniem się. Specjalistyczne skanowanie Supabase wymaga zweryfikowanej domeny oraz płatnej subskrypcji lub zakupionego kredytu; jego zasięg zależy od skonfigurowanego dostępu.