التأثير
يمكن للمهاجمين تجاوز منطق التطبيق لقراءة السجلات أو تحديثها أو حذفها في قاعدة البيانات إذا لم يتم فرض أمان مستوى الصف (RLS) بشكل صحيح. يؤدي هذا غالبًا إلى كشف معلومات التعريف الشخصية (PII) أو بيانات التطبيق الحساسة للمستخدمين الذين لديهم فقط إمكانية الوصول إلى مفتاح API العام المجهول.
السبب الجذري
يستخدم Supabase Postgres Row Level Security لإدارة الوصول إلى البيانات على مستوى قاعدة البيانات، وهو أمر أساسي لتأمين البيانات [S1]. في بيئة Next.js، يجب على المطورين إنشاء عميل Supabase الذي يتعامل بشكل صحيح مع ملفات تعريف الارتباط وجلسات العمل للحفاظ على الأمان أثناء العرض من جانب الخادم [S2]. تنشأ نقاط الضعف عادةً عندما:
- يتم إنشاء الجداول دون تمكين RLS، مما يجعلها قابلة للوصول عبر المفتاح المجهول العام [S1].
- تم تكوين عميل Supabase بشكل خاطئ في Next.js، مما أدى إلى الفشل في تمرير الرموز المميزة لمصادقة المستخدم بشكل صحيح إلى قاعدة البيانات [S2].
- يستخدم المطورون عن طريق الخطأ مفتاح
service_roleفي التعليمات البرمجية من جانب العميل، مما يتجاوز جميع سياسات RLS [S1].
الإصلاحات الخرسانية
- تمكين RLS: تأكد من تمكين أمان مستوى الصف لكل جدول في قاعدة بيانات Supabase [S1].
- تحديد السياسات: أنشئ سياسات Postgres محددة لعمليات
SELECTوINSERTوUPDATEوDELETEلتقييد الوصول بناءً على UID الخاص بالمستخدم [S1]. - استخدام عملاء SSR: قم بتنفيذ حزمة
@supabase/ssrلإنشاء عملاء في Next.js الذين يديرون المصادقة من جانب الخادم واستمرارية الجلسة بشكل صحيح [S2].
كيفية اختبار FixVibe لذلك
يغطي FixVibe هذا بالفعل من خلال عمليات التحقق من التطبيقات المنشورة والريبو. تكتشف وحدة baas.supabase-rls السلبية عنوان URL لـ Supabase وأزواج المفاتيح المجهولة من حزم JavaScript ذات الأصل نفسه، وتطلب من PostgREST بيانات تعريف الجدول العام، وتقوم بإجراء تحديدات محدودة للقراءة فقط لتأكيد الكشف عن البيانات المجهولة دون تغيير بيانات العميل. تقوم عمليات فحص الريبو أيضًا بتشغيل repo.supabase.missing-rls لوضع علامة على عمليات ترحيل SQL التي تنشئ جداول عامة بدون ENABLE ROW LEVEL SECURITY، وتبحث عمليات الفحص السرية عن الكشف عن مفتاح دور الخدمة قبل أن تصل إلى المتصفح.