Supabase RLS: manuelles Audit oder Scan?

Sicherheit auf Zeilenebene ist die Grenze zwischen einem Supabase-Projekt, das seine Daten schützt, und einem Projekt, das sie stillschweigend offenlegt. Wenn RLS gut konfiguriert ist, erzwingt Ihre Datenbank Zugriffsregeln auf Zeilenebene für Rollen, die RLS unterliegen. Privilegierte Rollen, einschließlich der Servicerolle, können diese Regeln umgehen. Wenn es schlecht konfiguriert ist, sehen die Tabellen geschützt aus, während die Richtlinien mehr durchlassen, als Sie beabsichtigt haben.

In diesem Artikel werden zwei Möglichkeiten zur Durchführung einer Supabase RLS-Sicherheitsüberprüfung verglichen: die manuelle Überprüfung von Richtlinien und die Durchführung einer automatisierten RLS-Prüfung. Beide haben ihren Platz. Wenn Sie wissen, wo die einzelnen Fehler liegen, können Sie überprüfen, ob Ihre Datenbankzugriffsrichtlinien wie vorgesehen funktionieren.

RLS ist eine Postgres-Funktion, die Supabase pro Tabelle verfügbar macht. Sobald eine Tabelle aktiviert ist, verweigert sie Rollen, die RLS unterliegen, den Zeilenzugriff, es sei denn, eine Richtlinie lässt dies zu. Ausnahmen bilden Tabelleneigentümer und Rollen mit Bypass-Berechtigungen. Richtlinien werden anhand des aktuellen Benutzers, seiner Ansprüche und der ausgeführten Abfrage ausgewertet. Die auth.uid() Funktion ist normalerweise der Anker: eine Richtlinie wie using (auth.uid() = user_id) Beschränkt den Zugriff auf die eigenen Datenbankzeilen des angemeldeten Benutzers.

Das Modell ist sauber. Die Misserfolge sind es nicht, denn sie sehen selten wie Misserfolge aus.

Einige Muster sind für die meisten RLS-Probleme verantwortlich:

• RLS ist für einige Tabellen aktiviert, nicht für alle. Eine nach dem Start hinzugefügte oder durch eine Migration erstellte neue Tabelle kann mit deaktiviertem RLS ausgeliefert werden. Jede Zeile ist dann für jede Rolle mit Tabellenzugriff lesbar.

• Eine Politik, die umfassender ist, als sie liest. using (true) Bei einer ausgewählten Richtlinie bedeutet dies, dass jede Zeile sichtbar ist. Es ist leicht, es während der Entwicklung zum Debuggen hinzuzufügen und zu vergessen, es zu entfernen.

• Die Dienstrolle wird überall übernommen. Serverseitiger Code, der den Dienstrollenschlüssel verwendet, umgeht RLS vollständig. Wenn benutzerseitige Anforderungen über diesen Schlüssel laufen, gelten die Richtlinien nie.

• Richtlinien, die die falsche Spalte überprüfen. auth.uid() = id auf einem Tisch, wo id Ist der Primärschlüssel der Zeile und nicht der Eigentümer, wird er niemals mit der Absicht übereinstimmen. Die Richtlinie ist vorhanden, sie gibt einen Fehler oder einen leeren Satz zurück und die Oberfläche verhält sich weiterhin.

• Datenbankaktualisierungen und -löschungen ohne entsprechende Zugriffskontrollen. Entwickler sichern die Auswahl häufig gründlich und lassen die Schreibrichtlinien locker. Das Bestehen einer Leseprüfung sagt nichts darüber aus, wer die Zeile als nächstes ändern kann.

Keines davon meldet sich. Jeder von ihnen sorgt dafür, dass die App funktioniert, und das ist genau der Grund, warum sie bis zur Produktion überleben.

Eine manuelle Prüfung erfolgt direkt und erfordert keine neuen Tools. Sie arbeiten die Richtlinien selbst Tabelle für Tabelle durch.

Beginnen Sie damit, jede Tabelle aufzulisten und zu bestätigen, dass RLS für jede Tabelle aktiviert ist. Listen Sie dann für jede Tabelle die Richtlinien auf und ordnen Sie sie dem beabsichtigten Zugriff zu: Wer sollte lesen, wer schreiben und wer sollte sie niemals berühren. Lesen Sie jeden Richtlinienausdruck anhand der Spalte, die er vergleicht. Bestätigen Sie, dass „Auswählen“, „Einfügen“, „Aktualisieren“ und „Löschen“ jeweils über eine Richtlinie verfügen, die der beabsichtigten Rolle entspricht.

Überprüfen Sie als Nächstes den Codepfad. Bestimmen Sie, welchen Schlüssel Ihre Anwendung tatsächlich für benutzerbezogene Anforderungen verwendet und ob einer davon über die Dienstrolle ausgeführt wird. Schreiben Sie dann Testabfragen für verschiedene Benutzer und bestätigen Sie, dass die Ergebnisse den Erwartungen entsprechen: Ein Benutzer sollte seine eigenen Zeilen und die von niemand anderem lesen und sollte nicht in der Lage sein, eine Zeile zu aktualisieren, die ihm nicht gehört.

Eine manuelle Überprüfung lohnt sich, und sie fängt viel auf. Es gibt auch vorhersehbare tote Winkel.

• Es testet, was Sie zu testen vergessen haben. Wenn Sie nicht daran denken, als zweiter Benutzer einen Löschvorgang durchzuführen, übersehen Sie möglicherweise eine zu weit gefasste Löschrichtlinie. Wenn RLS aktiviert ist, bedeutet keine anwendbare Löschrichtlinie, dass das Löschen verweigert wird.

• Es altert. Richtlinien ändern sich, wenn Funktionen hinzugefügt werden. Eine gründliche Überprüfung im letzten Quartal sagt nichts über die Tabelle aus, die Sie letzte Woche hinzugefügt haben.

• Es hängt von derselben Person ab, die die Richtlinien konfiguriert hat. Der Bauunternehmer, der die Richtlinie verfasst hat, wird seine eigene Annahme am wenigsten erkennen.

• Es braucht aufgezeichnete Beweise. „Ich habe es überprüft und es sah richtig aus“ hinterlässt nichts: keine Beweise, kein Zielfernrohr, kein Artefakt, das Sie später erneut scannen können.

Manuelles Auditing beantwortet die Frage: „Entspricht dies meinem mentalen Modell des Systems?“ Es allein beweist nicht, was die Datenbank tatsächlich zurückgibt.

Eine automatisierte Supabase RLS Sicherheitsüberprüfung funktioniert aus der anderen Richtung. Es übt das Projekt so aus, wie es ein Angreifer oder ein falsch konfigurierter Client tun würde, und meldet, was die Datenschicht tatsächlich zulässt.

Diese Verschiebung ist aus drei Gründen wichtig. Erstens skaliert es über den Speicher hinaus: Der Scan wiederholt Überprüfungen für alle Tabellen und Endpunkte, die innerhalb seines konfigurierten Bereichs verfügbar sind. Ohne geeigneten Zugriff kann ein externer Scan nicht jede Richtlinie überprüfen. Zweitens liefert es Beweise, auf die Sie reagieren können: Das Ergebnis benennt die Tabelle, den Richtlinienstatus und die Bedingung, die sie erreichbar gemacht hat, sodass Sie wissen, was und warum geändert werden muss. Drittens ist es wiederholbar. Durch eine erneute Überprüfung wird aus einer einmaligen Überprüfung eine fortlaufende Überprüfung.

VICE scannt Webanwendungen und Supabase/RLS-Konfigurationen und meldet dann Ergebnisse mit den dahinter stehenden Beweisen und Korrekturanleitungen, anhand derer gearbeitet werden kann. Sie können einen Fix markieren und eine erneute Überprüfung anfordern, aber nur ein vergleichbarer erneuter Scan bestätigt, dass das Problem behoben ist: Der Fix wird anhand desselben Bereichs überprüft und nicht aus der Bearbeitung übernommen. Geplante Scans und Warnungen unterstützen die laufende Überwachung, sodass eine im nächsten Monat hinzugefügte Tabelle die Lücke nicht stillschweigend wieder einführt.

Die Arbeitsteilung ist unkompliziert. Führen Sie die automatische Prüfung durch, um herauszufinden, was bei Ihrer manuellen Überprüfung übersehen wurde, und verwenden Sie dann einen manuellen Durchgang, um die Absicht hinter jeder Richtlinie zu bestätigen, die der Scan kennzeichnet. Die Automatisierung sagt Ihnen, was die Datenbank zulässt; Sie entscheiden, ob diese Erlaubnis absichtlich erfolgte.

Ein Ergebnis eines beliebigen Scans beschreibt den getesteten Umfang und ist keine Garantie dafür, dass ein Projekt vollständig sicher ist. Betrachten Sie es als Hinweis darauf, wo Sie suchen müssen, nicht als Zertifikat.

Wenn Sie ein mit Supabase erstelltes Produkt bereitstellen und Ihre Richtlinien noch nie geprüft haben, lautet die ehrliche Antwort: Beides in Ordnung. Beginnen Sie mit einer automatisierten RLS-Prüfung, damit Sie ein aktuelles, evidenzbasiertes Bild davon haben, was Ihre Tische zulassen. Gehen Sie dann die Ergebnisse manuell durch, bestätigen Sie die Absicht der einzelnen Richtlinien und korrigieren Sie diejenigen, die abweichen. Legen Sie für die automatische Prüfung einen Zeitplan fest, damit neue Tabellen und neue Richtlinien der gleichen Prüfung unterzogen werden wie die Originale.

Das Überspringen beider Ansätze kann dazu führen, dass eine Datenbankzugriffsrichtlinie entsteht, die scheinbar Daten schützt, aber dennoch unbefugten Zugriff zulässt.

Starten Sie einen kostenlosen Scan Besuchen Sie vice-platform.com, um Ihre öffentliche Website zu überprüfen, bevor Sie sich anmelden. Für einen speziellen Supabase-Scan sind eine verifizierte Domain und ein kostenpflichtiges Abonnement oder ein erworbenes Guthaben erforderlich. seine Abdeckung hängt vom konfigurierten Zugang ab.