FixVibe
Covered by FixVibehigh

Unbefugter Datenzugriff durch fehlende Supabase-Sicherheit auf Zeilenebene (RLS)

In Supabase-gestützten Anwendungen basiert die Datensicherheit auf der Sicherheit auf Zeilenebene (RLS). Wenn RLS nicht explizit aktiviert und mit Richtlinien konfiguriert ist, kann jeder Benutzer mit dem öffentlichen anonymen Schlüssel Daten in der gesamten Datenbank lesen, aktualisieren oder löschen. Dies ist besonders wichtig in Next.js-Umgebungen, in denen der Supabase-Client häufig mit einem öffentlichen API-Schlüssel initialisiert wird.

CWE-284

Auswirkungen

Wenn die Zeilenebenensicherheit (RLS) nicht implementiert wird, können nicht authentifizierte Angreifer Daten aus einer Supabase-Datenbank abfragen, wenn öffentliche Tabellen über die anonyme Grenze [S1] verfügbar gemacht werden. Da Next.js-Anwendungen normalerweise den Schlüssel Supabase anon im clientseitigen Code offenlegen, kann ein Angreifer diesen Schlüssel verwenden, um direkte REST-Aufrufe API an die Datenbank durchzuführen und dabei die vorgesehene Anwendungslogik zu umgehen und auf vertrauliche Benutzerinformationen [S2] zuzugreifen.

Grundursache

Standardmäßig erfordern Postgres-Tabellen in Supabase eine explizite Aktivierung der Zeilenebenensicherheit, um den öffentlichen Zugriff [S1] zu verhindern. Wenn ein Entwickler eine Tabelle erstellt, aber vergisst, RLS zu aktivieren, oder es versäumt, restriktive Richtlinien zu definieren, kann die Datenbank Daten für jeden offenlegen, der über den anon-Schlüssel [S1] des Projekts verfügt. In Next.js-Anwendungen erfordern serverseitiges Rendering und clientseitiges Abrufen auch eine sorgfältige Einrichtung des Supabase-Clients, damit der authentifizierte Benutzerkontext die Datenbankebene [S2] erreicht.

Konkrete Korrekturen

  • RLS aktivieren: Führen Sie ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY; für jede öffentliche Tabelle aus, in der App-Daten [S1] gespeichert sind.
  • Richtlinien definieren: Erstellen Sie spezifische Richtlinien, die den Zugriff basierend auf dem Authentifizierungsstatus des Benutzers einschränken, z. B. CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id); [S1].
  • Sichere serverseitige Clients: Wenn Sie Next.js verwenden, belassen Sie die Dienstrollen-Clients nur auf dem Server und wenden Sie weiterhin Besitzfilter an, bevor Sie Daten an die Benutzer [S2] zurückgeben.

Wie FixVibe darauf testet

FixVibe führt bereits eine schreibgeschützte Supabase RLS-Prüfung über baas.supabase-rls aus. Der Scanner erkennt die Supabase-Projekt-URL und den öffentlichen Anonymschlüssel aus JavaScript-Bundles gleichen Ursprungs, fragt PostgREST nach öffentlichen Tabellenmetadaten und versucht begrenzte schreibgeschützte Auswahlen, um zu bestätigen, ob Daten ohne Benutzersitzung verfügbar gemacht werden. Es werden keine Dienstrollenanmeldeinformationen eingefügt, aktualisiert, gelöscht oder verwendet. Repo-Scans können dies auch früher erkennen, indem repo.supabase.missing-rls SQL-Migrationen kennzeichnet, die öffentliche Tabellen ohne ENABLE ROW LEVEL SECURITY erstellen.