השפעה
כשל ביישום אבטחת רמת השורה (RLS) מאפשר לתוקפים לא מאומתים לבצע שאילתות לנתונים ממסד נתונים Supabase כאשר טבלאות ציבוריות נחשפות דרך הגבול האנון [S1]. מכיוון שיישומי Next.js בדרך כלל חושפים את מפתח Supabase anon בקוד בצד הלקוח, תוקף יכול להשתמש במפתח זה כדי לבצע קריאות REST API ישירות למסד הנתונים, תוך גישה למידע הרגיש של המשתמש המיועד וגישה למידע הרגיש של האפליקציה. [S2].
סיבת שורש
כברירת מחדל, טבלאות Postgres ב-Supabase דורשות הפעלה מפורשת של Row Level Security כדי למנוע גישה ציבורית [S1]. כאשר מפתח יוצר טבלה אך שוכח להפעיל את RLS או לא מצליח להגדיר מדיניות מגבילה, מסד הנתונים עלול לחשוף נתונים לכל מי שיש לו מפתח anon של הפרויקט [S1]. ביישומי 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.