Կեռիկը
Supabase նախագծի ապահովումը պահանջում է բազմաշերտ մոտեցում՝ կենտրոնանալով API բանալիների կառավարման, տվյալների բազայի անվտանգության և պահեստավորման թույլտվությունների վրա: [S1] Անպատշաճ կազմաձևված տողերի մակարդակի անվտանգությունը (RLS) կամ բաց զգայուն ստեղները կարող են հանգեցնել տվյալների բացահայտման զգալի միջադեպերի: [S2] [S3]
Ինչ փոխվեց
Այս հետազոտությունը համախմբում է Supabase միջավայրերի անվտանգության հիմնական վերահսկումները՝ հիմնված ճարտարապետության պաշտոնական ուղեցույցների վրա: [S1] Այն կենտրոնանում է զարգացման լռելյայն կոնֆիգուրացիաներից դեպի արտադրական կարծրացած կեցվածքների անցումը՝ մասնավորապես մուտքի վերահսկման մեխանիզմների վերաբերյալ: [S2] [S3]
Ով է տուժում
Այն հավելվածները, որոնք օգտագործում են Supabase-ը որպես Backend-որպես ծառայություն (BaaS), տուժում են, հատկապես նրանք, որոնք մշակում են օգտատիրոջ հատուկ տվյալներ կամ մասնավոր ակտիվներ: [S2] Մշակողները, ովքեր service_role բանալին ներառում են հաճախորդի կողմից նախատեսված փաթեթներում կամ չեն կարողանում միացնել RLS-ը, բարձր ռիսկի տակ են: [S1]
Ինչպես է խնդիրը աշխատում
Supabase-ն օգտագործում է PostgreSQL-ի շարքի մակարդակի անվտանգությունը՝ տվյալների հասանելիությունը սահմանափակելու համար: [S2] Լռելյայնորեն, եթե RLS միացված չէ սեղանի վրա, anon բանալի ունեցող ցանկացած օգտվող, որը հաճախ հանրային է, կարող է մուտք գործել բոլոր գրառումները: [S1] Նմանապես, Supabase Պահպանումը պահանջում է հստակ քաղաքականություն՝ սահմանելու համար, թե որ օգտվողները կամ դերերը կարող են գործողություններ կատարել ֆայլերի դույլերի վրա: [S3]
Ինչ է ստանում հարձակվողը
Հարձակվողը, որն ունի հանրային API բանալի, կարող է օգտագործել RLS բացակայող աղյուսակները՝ կարդալու, փոփոխելու կամ ջնջելու այլ օգտվողներին պատկանող տվյալները: [S1] [S2] Պահեստային դույլեր չարտոնված մուտքը կարող է հանգեցնել օգտատիրոջ մասնավոր ֆայլերի բացահայտմանը կամ հավելվածի կարևոր ակտիվների ջնջմանը: [S3]
Ինչպես է FixVibe-ն փորձարկում դրա համար
FixVibe-ն այժմ ծածկում է սա որպես իր Supabase չեկերի մաս: baas.supabase-security-checklist-backfill-ն վերանայում է հանրային Supabase Պահպանման դույլի մետատվյալները, օբյեկտների ցանկի անանուն բացահայտումը, զգայուն դույլի անվանումը և անսահմանափակ պահեստավորման ազդանշանները հանրային անոնց սահմանից: Առնչվող ուղիղ ստուգումները ստուգում են ծառայության դերի բանալիների բացահայտումը, Supabase REST/RLS կեցվածքը և պահեստի SQL միգրացիաները՝ RLS բացակայելու համար:
Ինչ ուղղել
Միշտ միացրեք տողերի մակարդակի անվտանգությունը տվյալների բազայի աղյուսակներում և կիրառեք հստակ քաղաքականություն վավերացված օգտատերերի համար: [S2] Համոզվեք, որ հաճախորդի կողմից օգտագործվող կոդում միայն «anon» բանալին է, մինչդեռ «service_role» ստեղնը մնում է սերվերում: [S1] Կարգավորեք Storage Access Control-ը, որպեսզի համոզվեք, որ ֆայլերի դույլերը լռելյայնորեն մասնավոր են, և մուտքը տրվում է միայն սահմանված անվտանգության քաղաքականության միջոցով: [S3]