BaaS misconfiguration scanner៖ រកផ្លូវទិន្នន័យសាធារណៈមុនពេលអ្នកប្រើ

ហេតុអ្វីការកំណត់រចនាសម្ព័ន្ធខុស BaaS មានរូបរាងជាប់លាប់

រាល់វេទិកា BaaS អនុវត្តតាមស្ថាបត្យកម្មដូចគ្នា៖ backend ដែលគ្រប់គ្រងជាមួយ client SDK ស្ដើងដែលនិយាយជាមួយវាពី browser។ Client ប្រឈមមុខ browser ត្រូវការ credential ខ្លះ — anon key, publishable key, Firebase project ID — ដើម្បីកំណត់អត្តសញ្ញាណខ្លួនវាទៅ backend។ Credential នោះមានចេតនាសាធារណៈ; សុវត្ថិភាពនៃស្ថាបត្យកម្មពឹងផ្អែកលើការគ្រប់គ្រងការចូលប្រើកម្រិតវេទិកា (RLS, ច្បាប់, allowlist) ដែលធ្វើការងាររបស់ពួកវា។

ឧបករណ៍សរសេរកូដ AI ស្ថាបនាលើស្ថាបត្យកម្មនេះដោយមិន internalise ផ្នែកគ្រប់គ្រងវេទិកា។ ពួកវាភ្ជាប់ client SDK ត្រឹមត្រូវ, ទទួលយកច្បាប់លំនាំដើមអនុញ្ញាតរបស់វេទិកា (ដែលមានសម្រាប់ភាពងាយស្រួលនៃ tutorial) និង ship។ រូបរាងជាប់លាប់គឺ៖ credential សាធារណៈ + ច្បាប់លំនាំដើមអនុញ្ញាត + ការ override បាត់ = ការបង្ហាញទិន្នន័យ។ ថ្នាក់ការកំណត់រចនាសម្ព័ន្ធខុសប្រាំខាងក្រោមគឺជា variant នៃរូបរាងនេះទាំងអស់។

ថ្នាក់ការកំណត់រចនាសម្ព័ន្ធខុសជាប់លាប់ប្រាំ

ទាំងនេះលេចឡើងនៅទូទាំង BaaS provider នីមួយៗ។ Scan ពេញលេញគ្របដណ្ដប់ទាំងប្រាំប្រឆាំងនឹង provider នីមួយៗដែលប្រើ៖

ថ្នាក់ទី 1៖ Key ខុសក្នុង bundle browser

Browser ship secret/admin key (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) ជំនួសឱ្យសមមូលសាធារណៈ/anon។ Browser ក្លាយជា client admin គ្មានព្រំដែន។ គ្របដណ្ដប់ដោយ ការត្រួតពិនិត្យ bundle-secrets របស់ FixVibe។

ថ្នាក់ទី 2៖ ផ្នែកគ្រប់គ្រងការចូលប្រើបិទ ឬអនុញ្ញាត

RLS បិទ, ច្បាប់ Firebase គឺ if true, បញ្ជី callback Auth0 មាន wildcard។ Credential ក្នុង browser គឺត្រឹមត្រូវ — តែព្រំដែនកម្រិតវេទិកាដែលមានបំណងកំណត់វាមិនធ្វើការងាររបស់វា។

ថ្នាក់ទី 3៖ ការអាន anonymous នៃធនធានរសើប

Collection Firestore ដែលអាចអាន anon, bucket Supabase storage ដែលអាចរាយ anon, Auth0 management API ដែលអាចចូលប្រើ anon។ Scan សួរ៖ "ដោយគ្មាន credential, ខ្ញុំអាចអានអ្វី?"

ថ្នាក់ទី 4៖ Artefact test-mode នៅក្នុងផលិតកម្ម

Test key (pk_test_*, sb_test_*) ក្នុង deploy ផលិតកម្ម; កម្មវិធី Firebase dev-mode អាចទាក់ទងបានពី domain live; កម្មវិធី Auth0 test-tenant ជាមួយការកំណត់ខ្សោយជាងផលិតកម្ម។ Scan ប្រៀបធៀប key runtime ប្រឆាំងនឹង prefix ផលិតកម្មដែលរំពឹង។

ថ្នាក់ទី 5៖ ការផ្ទៀងផ្ទាត់ហត្ថលេខា webhook បាត់

Webhook Clerk, Stripe webhook, Supabase webhook ទាំងអស់ចុះហត្ថលេខា payload របស់ពួកវា។ Handler ដែលមិនផ្ទៀងផ្ទាត់ហត្ថលេខាគឺជា primitive សរសេរ database សម្រាប់អ្នកវាយប្រហារណាមួយដែលទាយ URL។ រកឃើញតាមរយៈរូបរាង response — request មិនមានហត្ថលេខាដែលទទួល 200 មានន័យថាការផ្ទៀងផ្ទាត់ត្រូវបានរំលង។

របៀបដែលឆ័ត្រ FixVibe BaaS scan ដំណើរការ

ដំណាក់កាល BaaS របស់ FixVibe ដំណើរការក្នុងបីដំណាក់កាល, នីមួយៗបង្កើត finding ផ្សេងគ្នា៖

1. <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
2. ដំណាក់កាលទី 2 — probe ជាក់លាក់ provider។ សម្រាប់ provider នីមួយៗដែលរកឃើញ, scanner ដំណើរការការត្រួតពិនិត្យជាក់លាក់ provider៖ baas.supabase-rls ត្រួតពិនិត្យ PostgREST; baas.firebase-rules ត្រួតពិនិត្យ Firestore + RTDB + Storage; baas.clerk-auth0 ផ្ទៀងផ្ទាត់ prefix នៃ key ដែល bundled; ការត្រួតពិនិត្យ bundle-secrets ផ្ទៀងផ្ទាត់ថាគ្មាន credential service-tier លេចធ្លាយ។ Probe នីមួយៗដំណើរការដោយឯករាជ្យ — finding Supabase មិនរារាំង Firebase scan។
3. ដំណាក់កាលទី 3 — ការទាក់ទង cross-provider។ Scanner ឆ្លងយោងលើ finding។ Supabase service-role key ដែលលេចធ្លាយក្បែរ RLS ដែលបាត់គឺធ្ងន់ធ្ងរជាងណាមួយ — របាយការណ៍លើកស្ទុយនេះ។ identity provider ច្រើន (Clerk + Auth0 + custom auth) ក្នុងកម្មវិធីដូចគ្នាគឺជា finding រចនាសម្ព័ន្ធដែលសម្គាល់សម្រាប់ការពិនិត្យ។

Probe នីមួយៗគឺ passive៖ ច្រើនបំផុតមួយការអាន anonymous ក្នុងធនធាននីមួយៗ, ជាមួយរូបរាង response ដែលកត់ត្រា តែមាតិកា row មិនដែល paginated ឬរក្សា។ Probe សរសេរ និងកែប្រែត្រូវបានរារាំងនៅពីក្រោយការផ្ទៀងផ្ទាត់ភាពជាម្ចាស់ domain — ពួកវាមិនដែលដំណើរការប្រឆាំងនឹង target ដែលមិនបានផ្ទៀងផ្ទាត់។

អ្វីដែល scanner រកឃើញក្នុង provider នីមួយៗ

BaaS provider នីមួយៗមានផ្ទៃ និងយុទ្ធសាស្ត្រ scan ផ្សេងគ្នា។ នេះគឺជាអ្វីដែលគ្របដណ្ដប់៖

• Supabase៖ RLS ដែលបាត់នៅលើតារាង, bucket storage អាចរាយ anon, JWT service_role ដែលលេចធ្លាយ ឬ key sb_secret_* ក្នុង bundle, schema ដែលបង្ហាញតាមរយៈបញ្ជី OpenAPI anonymous។ សូមមើល Supabase RLS scanner និង Storage checklist។
• Firebase៖ ច្បាប់ if true លើ Firestore, Realtime Database និង Cloud Storage; bucket Storage អាចរាយ anon; ការអនុវត្ត App Check បាត់។ សូមមើល Firebase rules scanner និង ការពន្យល់ច្បាប់ if-true។
• Clerk៖ sk_* secret key ដែល bundled, pk_test_* ក្នុងផលិតកម្ម, ការផ្ទៀងផ្ទាត់ហត្ថលេខា webhook បាត់, origin ដែលអនុញ្ញាត wildcard។ សូមមើល Clerk checklist។
• Auth0៖ Client secret ដែល bundled, Implicit grant បើក, URL callback / logout wildcard, PKCE បាត់នៅលើ SPA។ សូមមើល Auth0 checklist។

របៀបដែល BaaS scanner ប្រៀបធៀបទៅ DAST និងឧបករណ៍ SAST ទូទៅ

Scanner BaaS-aware ធ្វើការងារជាក់លាក់ដែលឧបករណ៍ផ្សេងទៀតមិនធ្វើ។ ការប្រៀបធៀប៖

Scope ស្មោះត្រង់៖ អ្វីដែល scanner នេះមិនជំនួស

Scanner DAST BaaS-aware គឺជាឧបករណ៍ផ្ដោត មិនមែនជាកម្មវិធីសុវត្ថិភាពពេញលេញ។ វាមិន៖

• ជំនួស SAST ឬ SCA។ Static analysis រកឃើញ CVE dependency (Snyk, Semgrep) និងភាពងាយរងគ្រោះកម្រិតកូដ (SonarQube) ដែល scanner DAST មិនអាច។ ដំណើរការទាំងពីរ។
• ជំនួសការសាកល្បងជ្រៀតចូលដោយដៃ។ Pentester មនុស្សរកឃើញ flaw តក្កពាណិជ្ជកម្ម, ករណីដាច់ស្រយាល authorization និងភាពងាយរងគ្រោះច្រវាក់ដែលគ្មាន scanner អាច។ ជួល pentester មុនការដាក់ឱ្យដំណើរការធំ ឬការត្រួតពិនិត្យ compliance។
• ត្រួតពិនិត្យកូដ ឬ repo របស់អ្នកសម្រាប់ secret ក្នុងប្រវត្តិ git។ ការត្រួតពិនិត្យ bundle-secrets គ្របដណ្ដប់អ្វីដែលបច្ចុប្បន្ន deployed មិនមែនអ្វីដែលប្រវត្តិសាស្ត្រ committed។ ប្រើ git-secrets ឬ gitleaks សម្រាប់អនាម័យ repo។
• គ្របដណ្ដប់សេវាកម្ម backend មិនមែន BaaS។ បើកម្មវិធីរបស់អ្នកប្រើ backend ផ្ទាល់ខ្លួន (Express, Rails, Django, FastAPI), FixVibe scan ផ្ទៃ HTTP របស់វា តែមិនត្រួតពិនិត្យ database ឬហេដ្ឋារចនាសម្ព័ន្ធនៅពីក្រោយវាឡើយ។ នោះគឺជាដែន DAST + SAST ទូទៅ។

សំណួរសួរញឹកញាប់

ជំហានបន្ទាប់

ដំណើរការ FixVibe scan ឥតគិតថ្លៃប្រឆាំងនឹង URL ផលិតកម្មរបស់អ្នក — ការត្រួតពិនិត្យដំណាក់កាល BaaS ship លើគ្រប់ plan រួមទាំងកម្រិតឥតគិតថ្លៃ។ សម្រាប់ការជ្រៀតចូលជាក់លាក់ provider, អត្ថបទផ្ទាល់នៅក្នុងផ្នែកនេះគ្របដណ្ដប់ provider នីមួយៗយ៉ាងលម្អិត៖ Supabase RLS, ការបង្ហាញ Supabase service-key, Supabase storage, Firebase rules, Firebase if-true, Clerk និង Auth0។