التأثير
يسمح الفشل في تنفيذ أمان مستوى الصف (RLS) للمهاجمين غير المصادقين بالاستعلام عن البيانات من قاعدة بيانات Supabase عندما يتم كشف الجداول العامة عبر حدود [S1]. نظرًا لأن تطبيقات Next.js تكشف عادةً عن مفتاح Supabase anon في التعليمات البرمجية من جانب العميل، يمكن للمهاجم استخدام هذا المفتاح لإجراء مكالمات REST API مباشرة إلى قاعدة البيانات، وتجاوز منطق التطبيق المقصود والوصول إلى معلومات المستخدم الحساسة [S2].
السبب الجذري
افتراضيًا، تتطلب جداول Postgres في Supabase تنشيطًا صريحًا لأمان مستوى الصف لمنع الوصول العام إلى [S1]. عندما يقوم أحد المطورين بإنشاء جدول ولكنه ينسى تمكين RLS أو يفشل في تحديد السياسات المقيدة، فقد تعرض قاعدة البيانات البيانات لأي شخص يمتلك مفتاح anon الخاص بالمشروع. في تطبيقات Next.js، يتطلب العرض من جانب الخادم والجلب من جانب العميل أيضًا إعداد عميل Supabase بعناية بحيث يصل سياق المستخدم المصادق إلى طبقة قاعدة البيانات [S2].
الإصلاحات الخرسانية
- تمكين RLS: قم بتنفيذ
ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY;لكل جدول عام يخزن بيانات التطبيق [S1]. - تحديد السياسات: قم بإنشاء سياسات محددة تقيد الوصول بناءً على حالة مصادقة المستخدم، مثل
CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id);[S1]. - العملاء الآمنون من جانب الخادم: عند استخدام Next.js، احتفظ بعملاء دور الخدمة للخادم فقط واستمر في تطبيق عوامل تصفية الملكية قبل إعادة البيانات إلى المستخدمين [S2].
كيفية اختبار FixVibe لذلك
يقوم FixVibe بالفعل بتشغيل فحص Supabase RLS للقراءة فقط من خلال baas.supabase-rls. يكتشف الماسح الضوئي عنوان URL لمشروع Supabase ومفتاح مجهول عام من حزم JavaScript ذات الأصل نفسه، ويطلب من PostgREST بيانات تعريف الجدول العام، ويحاول تحديدات محدودة للقراءة فقط لتأكيد ما إذا كانت البيانات مكشوفة بدون جلسة مستخدم. ولا يقوم بإدراج بيانات اعتماد دور الخدمة أو تحديثها أو حذفها أو استخدامها. يمكن لعمليات فحص الريبو أيضًا اكتشاف ذلك مسبقًا من خلال repo.supabase.missing-rls، الذي يشير إلى عمليات ترحيل SQL التي تنشئ جداول عامة بدون ENABLE ROW LEVEL SECURITY.