Supabase RLS: تدقيق يدوي أم فحص آلي؟

أمان مستوى الصف هو الخط الفاصل بين مشروع Supabase الذي يحمي بياناته والآخر الذي يكشفها بهدوء. عندما يتم تكوين RLS بشكل جيد، تفرض قاعدة البيانات الخاصة بك قواعد الوصول على مستوى الصف، للأدوار الخاضعة لـ RLS. يمكن للأدوار المميزة، بما في ذلك دور الخدمة، تجاوز هذه القواعد. عندما يتم تكوينها بشكل سيئ، تبدو الجداول محمية بينما تسمح السياسات بتجاوز ما هو أكثر مما تريد.

تقارن هذه المقالة بين طريقتين لتشغيل فحص أمان Supabase RLS: التحقق من السياسات يدويًا، وتشغيل تدقيق RLS التلقائي. كلاهما لهما مكان. إن معرفة مكان تعطل كل منها هو كيفية التحقق من أن سياسات الوصول إلى قاعدة البيانات الخاصة بك تعمل على النحو المنشود.

RLS هي إحدى ميزات Postgres التي يعرضها Supabase لكل جدول. بمجرد التمكين، يرفض الجدول الوصول إلى الأدوار الخاضعة لـ RLS ما لم تسمح السياسة بذلك؛ يُعد مالكو الجدول والأدوار التي تتمتع بامتيازات التجاوز استثناءات. يتم تقييم السياسات وفقًا للمستخدم الحالي ومطالباته والاستعلام الجاري تشغيله. ال auth.uid() الوظيفة عادة ما تكون المرساة: سياسة مثل using (auth.uid() = user_id) يحد من الوصول إلى صفوف قاعدة البيانات الخاصة بالمستخدم الذي قام بتسجيل الدخول.

النموذج نظيف. أما حالات الفشل فهي ليست كذلك، لأنها نادرًا ما تبدو وكأنها حالات فشل.

بعض الأنماط تمثل معظم مشاكل RLS:

• تم تمكين RLS على بعض الجداول، وليس كلها. يمكن شحن جدول جديد يضاف بعد الإطلاق، أو جدول تم إنشاؤه من خلال الترحيل، مع إيقاف تشغيل RLS. يمكن بعد ذلك قراءة كل صف بواسطة أي دور لديه حق الوصول إلى الجدول.

• سياسة أوسع مما يقرأ. using (true) في سياسة محددة يعني أن كل صف مرئي. من السهل الإضافة أثناء التطوير لتصحيح الأخطاء ونسيان الإزالة.

• الدور الخدمي المفترض في كل مكان. رمز جانب الخادم الذي يستخدم مفتاح دور الخدمة يتجاوز RLS بالكامل. إذا تم تشغيل الطلبات التي تواجه المستخدم من خلال هذا المفتاح، فلن يتم تطبيق السياسات أبدًا.

• السياسات التي تتحقق من العمود الخاطئ. auth.uid() = id على طاولة حيث id هو المفتاح الأساسي للصف، وليس المالك، ولن يطابق القصد أبدًا. السياسة موجودة، وترجع خطأً أو مجموعة فارغة، ولا يزال السطح يتصرف.

• تحديثات قاعدة البيانات وحذفها دون ضوابط الوصول المناسبة. غالبًا ما يقوم المطورون بتأمين الاختيار بدقة وترك سياسات الكتابة فضفاضة. إن اجتياز فحص القراءة لا يوضح شيئًا عن من يمكنه تعديل الصف بعد ذلك.

لا أحد من هؤلاء يعلن عن نفسه. كل واحد منهم يحافظ على عمل التطبيق، وهذا هو بالضبط سبب بقائه حتى مرحلة الإنتاج.

التدقيق اليدوي مباشر ولا يتطلب أدوات جديدة. أنت تعمل من خلال السياسات نفسها، جدولًا تلو الآخر.

ابدأ بإدراج كل جدول والتأكد من تمكين RLS في كل جدول. ثم، بالنسبة لكل جدول، قم بتعداد السياسات ورسم خريطة للوصول المقصود: من يجب أن يقرأ، ومن يجب أن يكتب، ومن يجب ألا يلمسه أبدًا. اقرأ كل تعبير سياسة مقابل العمود الذي يقارنه. تأكد من أن التحديد والإدراج والتحديث والحذف لكل منها سياسة تتوافق مع الدور المقصود.

بعد ذلك، تحقق من مسار الكود. حدد المفتاح الذي يستخدمه تطبيقك فعليًا للطلبات التي تواجه المستخدم، وما إذا كان أي منها يعمل من خلال دور الخدمة. ثم اكتب استعلامات اختبار كمستخدمين مختلفين وتأكد من مطابقة النتائج للتوقعات: يجب على المستخدم قراءة الصفوف الخاصة به وليس صفوف أي شخص آخر، ويجب ألا يتمكن من تحديث صف لا يملكه.

المراجعة اليدوية تستحق القيام بها، وهي تحقق الكثير. كما أن لديها نقاط عمياء يمكن التنبؤ بها.

• إنه يختبر ما تتذكر اختباره. إذا كنت لا تفكر في تجربة الحذف كمستخدم ثانٍ، فقد تفوتك سياسة حذف واسعة جدًا. مع تمكين RLS، لا توجد سياسة حذف قابلة للتطبيق مما يعني أن الحذف مرفوض.

• إنه يتقدم في السن. تنجرف السياسات مع إضافة الميزات. المراجعة التي كانت شاملة في الربع الأخير لا تذكر شيئًا عن الجدول الذي أضفته الأسبوع الماضي.

• يعتمد ذلك على نفس الشخص الذي قام بتكوين السياسات. إن المنشئ الذي كتب السياسة هو الأقل احتمالاً لاكتشاف افتراضه الخاص.

• ويحتاج إلى أدلة مسجلة. "لقد قمت بمراجعته وبدا أنه صحيح" لا يترك أي شيء وراءه: لا يوجد دليل، ولا نطاق، ولا قطعة أثرية يمكنك إعادة فحصها لاحقًا.

يجيب التدقيق اليدوي على السؤال "هل يتوافق هذا مع نموذجي العقلي للنظام؟" وهو لا يثبت من تلقاء نفسه ما الذي ستعيده قاعدة البيانات فعليًا.

يعمل فحص الأمان الآلي Supabase RLS من الاتجاه الآخر. فهو يمارس المشروع بالطريقة التي يفعلها المهاجم أو العميل الذي تم تكوينه بشكل خاطئ، ويبلغ عما تسمح به طبقة البيانات فعليًا.

وهذا التحول مهم لثلاثة أسباب. أولاً، يقوم بقياس حجم الذاكرة السابقة: يقوم الفحص بتكرار عمليات التحقق عبر الجداول ونقاط النهاية المتوفرة ضمن النطاق الذي تم تكوينه. لا يمكن للفحص الخارجي فحص كل سياسة دون الوصول المناسب. ثانيًا، يقدم دليلاً يمكنك التصرف بناءً عليه: النتائج تسمي الجدول، وحالة السياسة، والحالة التي جعلته قابلاً للوصول، حتى تعرف ما الذي يجب تغييره ولماذا. ثالثا، أنها قابلة للتكرار. يؤدي الفحص الذي يمكنك إجراؤه مرة أخرى إلى تحويل المراجعة لمرة واحدة إلى تحقق مستمر.

يقوم VICE بفحص تطبيقات الويب وتكوينات Supabase/RLS، ثم يقوم بإبلاغ النتائج مع الأدلة التي تقف خلفها وإرشادات التصحيح للعمل بناءً عليها. يمكنك وضع علامة على الإصلاح وطلب إعادة الفحص، ولكن إعادة الفحص المماثلة فقط هي التي تؤكد حل المشكلة: يتم التحقق من الإصلاح مقابل نفس النطاق، ولا يُفترض من التعديل. تدعم عمليات الفحص والتنبيهات المجدولة المراقبة المستمرة، لذا فإن الجدول الذي تتم إضافته في الشهر التالي لا يعيد تقديم الفجوة بهدوء.

تقسيم العمل واضح ومباشر. قم بتشغيل الفحص الآلي للعثور على ما فاتك المراجعة اليدوية، ثم استخدم تصريحًا يدويًا لتأكيد الهدف وراء كل سياسة يشير إليها الفحص. تخبرك الأتمتة بما تسمح به قاعدة البيانات؛ عليك أن تقرر ما إذا كان هذا الإذن متعمدا.

تصف النتيجة من أي فحص النطاق الذي تم اختباره، وليس ضمانًا بأن المشروع آمن تمامًا. تعامل معها كإشارة إلى المكان الذي تبحث فيه، وليس كشهادة.

إذا كنت تقوم بنشر منتج تم إنشاؤه باستخدام Supabase ولم تقم مطلقًا بمراجعة سياساتك، فإن الإجابة الصادقة هي كليهما بالترتيب. ابدأ بفحص RLS الآلي حتى يكون لديك صورة حديثة مدعومة بالأدلة لما تسمح به جداولك. ثم قم بقراءة النتائج يدويًا، وتأكد من غرض كل سياسة، وأصلح السياسات التي انحرفت. قم بوضع الفحص الآلي ضمن جدول زمني حتى تحصل الجداول والسياسات الجديدة على نفس التدقيق الذي تخضع له الجداول الأصلية.

يمكن أن يؤدي تخطي أي من الطريقتين إلى ترك سياسة الوصول إلى قاعدة البيانات التي يبدو أنها تحمي البيانات ولكنها لا تزال تسمح بالوصول غير المصرح به.

ابدأ الفحص المجاني على Vice-platform.com للتحقق من موقع الويب العام الخاص بك قبل التسجيل. يتطلب فحص Supabase المتخصص نطاقًا تم التحقق منه واشتراكًا مدفوعًا أو رصيدًا تم شراؤه؛ تغطيتها تعتمد على الوصول المكوّن.