Supabase RLS: handmatige audit of scan?

Row Level Security is de grens tussen een Supabase-project dat zijn gegevens beschermt en een project dat deze stilletjes openbaar maakt. Wanneer RLS goed is geconfigureerd, dwingt uw database toegangsregels af op rijniveau, voor rollen die vallen onder RLS. Bevoorrechte rollen, inclusief de servicerol, kunnen deze regels omzeilen. Als het slecht is geconfigureerd, zien de tabellen er beschermd uit, terwijl het beleid meer doorlaat dan u had bedoeld.

Dit artikel vergelijkt twee manieren om een Supabase RLS-beveiligingscontrole uit te voeren: het handmatig verifiëren van beleid en het uitvoeren van een geautomatiseerde RLS-audit. Beiden hebben een plek. Als u weet waar elk programma kapot gaat, verifieert u of uw databasetoegangsbeleid werkt zoals bedoeld.

RLS is een Postgres-functie die Supabase per tabel weergeeft. Eenmaal ingeschakeld, weigert een tabel rijtoegang tot rollen die vallen onder RLS, tenzij een beleid dit toestaat; tabeleigenaren en rollen met omzeilrechten zijn uitzonderingen. Beleid wordt geëvalueerd op basis van de huidige gebruiker, zijn claims en de query die wordt uitgevoerd. De auth.uid() functie is meestal het anker: een beleid zoals using (auth.uid() = user_id) beperkt de toegang tot de eigen databaserijen van de aangemelde gebruiker.

Het model is schoon. De mislukkingen zijn dat niet, omdat ze zelden op mislukkingen lijken.

Een paar patronen zijn verantwoordelijk voor de meeste RLS-problemen:

• RLS is op sommige tafels ingeschakeld, niet op alle. Een nieuwe tabel die na de lancering wordt toegevoegd, of een tabel die via een migratie is gemaakt, kan worden geleverd met uitgeschakelde RLS. Elke rij is vervolgens leesbaar voor elke rol met tabeltoegang.

• Een beleid dat breder is dan er staat. using (true) bij een select beleid betekent dat elke rij zichtbaar is. Het is gemakkelijk toe te voegen tijdens de ontwikkeling voor foutopsporing en te vergeten te verwijderen.

• De dienstverlenende rol werd overal op zich genomen. Code aan de serverzijde die gebruikmaakt van de servicerolsleutel omzeilt RLS volledig. Als gebruikersgerichte verzoeken via die sleutel lopen, is het beleid nooit van toepassing.

• Beleid dat de verkeerde kolom aanvinkt. auth.uid() = id op een tafel waar id de primaire sleutel van de rij is, en niet de eigenaar, zal nooit overeenkomen met de bedoeling. Het beleid bestaat, het retourneert een fout of een lege set, en het oppervlak gedraagt ​​zich nog steeds.

• Database-updates en -verwijderingen zonder passende toegangscontroles. Ontwikkelaars beveiligen selectie vaak grondig en laten het schrijfbeleid los. Het passeren van een leescontrole zegt niets over wie de rij vervolgens kan wijzigen.

Geen van deze kondigt zichzelf aan. Ze zorgen er allemaal voor dat de app blijft werken, en dat is precies de reden waarom ze overleven tot aan de productie.

Een handmatige audit is direct en vereist geen nieuwe tools. Je werkt het beleid zelf door, tafel voor tafel.

Begin met het vermelden van elke tafel en controleer of RLS voor elke tafel is ingeschakeld. Vervolgens somt u voor elke tabel het beleid op en wijst u deze toe aan de beoogde toegang: wie moet lezen, wie moet schrijven en wie mag er nooit aan komen. Lees elke beleidsexpressie tegen de kolom waarmee deze wordt vergeleken. Bevestig dat selecteren, invoegen, bijwerken en verwijderen elk een beleid hebben dat overeenkomt met de beoogde rol.

Controleer vervolgens het codepad. Bepaal welke sleutel uw toepassing daadwerkelijk gebruikt voor gebruikersgerichte verzoeken, en of deze via de servicerol worden uitgevoerd. Schrijf vervolgens testquery's als verschillende gebruikers en bevestig dat de resultaten overeenkomen met de verwachtingen: een gebruiker moet zijn eigen rijen lezen en die van niemand anders, en mag geen rij kunnen bijwerken waarvan hij niet de eigenaar is.

Handmatige beoordeling is de moeite waard en levert veel op. Het heeft ook voorspelbare blinde vlekken.

• Het test wat je onthoudt om te testen. Als u er niet aan denkt om als tweede gebruiker een verwijdering uit te voeren, mist u mogelijk een te breed verwijderingsbeleid. Als RLS is ingeschakeld, betekent geen toepasselijk verwijderbeleid dat verwijdering wordt geweigerd.

• Het veroudert. Beleid verandert naarmate er functies worden toegevoegd. Een grondige review afgelopen kwartaal zegt niets over de tabel die je vorige week hebt toegevoegd.

• Het hangt af van dezelfde persoon die het beleid heeft geconfigureerd. De bouwer die het beleid heeft geschreven, zal het minst waarschijnlijk zijn eigen veronderstelling opmerken.

• Er is opgenomen bewijsmateriaal nodig. "Ik heb het beoordeeld en het zag er goed uit" laat niets achter: geen bewijs, geen reikwijdte, geen artefact dat je later opnieuw kunt scannen.

Handmatige auditing beantwoordt de vraag "komt dit overeen met mijn mentale model van het systeem?" Het bewijst op zichzelf niet wat de database daadwerkelijk zal opleveren.

Een geautomatiseerde Supabase RLS-veiligheidscontrole werkt vanuit de andere richting. Het oefent het project uit zoals een aanvaller of een verkeerd geconfigureerde client dat zou doen, en rapporteert wat de gegevenslaag feitelijk toestaat.

Die verschuiving is om drie redenen van belang. Ten eerste schaalt het voorbij het geheugen: de scan herhaalt controles over de tabellen en eindpunten die beschikbaar zijn binnen het geconfigureerde bereik. Zonder passende toegang kan een externe scan niet elk beleid inspecteren. Ten tweede levert het bewijsmateriaal op waar u actie op kunt ondernemen: de bevinding benoemt de tabel, de beleidsstatus en de voorwaarde die deze bereikbaar maakte, zodat u weet wat u moet veranderen en waarom. Ten derde is het herhaalbaar. Een controle die u opnieuw kunt uitvoeren, verandert een eenmalige beoordeling in een doorlopende verificatie.

De VICE scant webapplicaties en Supabase/RLS-configuraties en rapporteert vervolgens de bevindingen met het bewijs erachter en correctierichtlijnen om mee te werken. U kunt een oplossing markeren en een nieuwe controle aanvragen, maar alleen een vergelijkbare herscan bevestigt dat het probleem is opgelost: de oplossing wordt geverifieerd op basis van dezelfde reikwijdte en wordt niet overgenomen uit de bewerking. Geplande scans en waarschuwingen ondersteunen voortdurende monitoring, dus een tabel die volgende maand wordt toegevoegd, zal de kloof niet stilletjes opnieuw introduceren.

De taakverdeling is eenvoudig. Voer de automatische controle uit om te achterhalen wat er tijdens uw handmatige beoordeling is gemist en gebruik vervolgens een handmatige controle om de intentie achter elk beleid dat door de scan wordt gemarkeerd te bevestigen. Automatisering vertelt u wat de database toestaat; u beslist of die toestemming opzettelijk was.

Een score van een scan beschrijft de geteste reikwijdte, en is geen garantie dat een project volledig veilig is. Beschouw het als een signaal van waar je moet kijken, niet als een certificaat.

Als u een product implementeert dat is gebouwd met Supabase en uw beleid nog nooit heeft gecontroleerd, is het eerlijke antwoord beide: in orde. Begin met een geautomatiseerde RLS-controle, zodat u een actueel, wetenschappelijk onderbouwd beeld krijgt van wat uw tabellen toestaan. Loop vervolgens de bevindingen handmatig door, bevestig de bedoeling van elk beleid en repareer de beleidsmaatregelen die afwijken. Zet de geautomatiseerde controle in een schema, zodat nieuwe tabellen en nieuw beleid op dezelfde manier worden gecontroleerd als de oorspronkelijke.

Als u een van beide benaderingen overslaat, kan er sprake zijn van een databasetoegangsbeleid dat gegevens lijkt te beschermen, maar nog steeds ongeoorloofde toegang toestaat.

Start een gratis scan op vice-platform.com om uw openbare website te controleren voordat u zich aanmeldt. Voor een gespecialiseerde Supabase-scan zijn een geverifieerd domein en een betaald abonnement of gekocht tegoed vereist; de dekking is afhankelijk van de geconfigureerde toegang.