Сканер няправільных налад BaaS: знайдзіце публічныя шляхі да дадзеных раней за карыстальнікаў

Чаму няправільныя налады BaaS маюць паўтаральную форму

Кожная платформа BaaS прытрымліваецца той самай архітэктуры: кіруемы бэкэнд з тонкім кліенцкім SDK, які размаўляе з ім з браўзера. Кліент, скіраваны на браўзер, мае патрэбу ў нейкіх уліковых дадзеных — ключ anon, публікаваны ключ, ідэнтыфікатар праекта Firebase — каб ідэнтыфікаваць сябе бэкэнду. Гэтыя ўліковыя дадзеныя наўмысна публічныя; бяспека архітэктуры абапіраецца на тое, што кантроль доступу ўзроўню платформы (RLS, правілы, спісы дазволу) выконваюць сваю працу.

ШІ-інструменты кадавання будуюць на гэтай архітэктуры без інтэрналізацыі пласта кантролю платформы. Яны падключаюць кліенцкі SDK правільна, прымаюць дазвольныя значэнні па змаўчанні платформы (якія існуюць для падручніка-сяброўства) і адпраўляюць. Паўтаральная форма: публічныя ўліковыя дадзеныя + дазвольнае правіла па змаўчанні + адсутны пераазначэнне = раскрыццё дадзеных. Пяць класаў няправільных налад ніжэй — усе варыянты гэтай формы.

Пяць паўтаральных класаў няправільных налад

Яны з'яўляюцца ў кожнага пастаўшчыка BaaS. Поўнае сканаванне ахоплівае ўсе пяць супраць кожнага выкарыстоўванага пастаўшчыка:

Клас 1: Няправільны ключ у браўзерным бандле

Браўзер адпраўляе сакрэтны/адмінскі ключ (Supabase service_role, прыватны ключ Firebase Admin SDK, Clerk sk_*, кліенцкі сакрэт Auth0) замест публічнага/anon эквівалента. Браўзер становіцца неабмежаваным адмінскім кліентам. Ахоплена праверкай bundle-secrets FixVibe.

Клас 2: Пласт кантролю доступу адключаны або дазвольны

RLS адключаны, правілы Firebase — гэта if true, спіс callback Auth0 — з падстаноўным знакам. Уліковыя дадзеныя ў браўзеры — правільныя, але мяжа ўзроўню платформы, якая павінна была абмежаваць іх, не выконвае сваю працу.

Клас 3: Ананімныя чытанні адчувальных рэсурсаў

Anon-чытальныя калекцыі Firestore, anon-пералічальныя сховішчы Supabase, anon-даступнае Management API Auth0. Сканаванне пытае: "без уліковых дадзеных, што я магу прачытаць?"

Клас 4: Артэфакты тэставага рэжыму ў прадакшэне

Тэставыя ключы (pk_test_*, sb_test_*) у прадукцыйным разгортванні; dev-рэжым праграм Firebase, дасягальных з жывога дамена; тэставыя арандатары Auth0 з больш слабымі наладамі, чым прадакшэн. Сканаванне параўноўвае ключы часу выканання з чаканымі прадукцыйнымі прэфіксамі.

Клас 5: Адсутная праверка подпісу вэбхука

Вэбхукі Clerk, вэбхукі Stripe, вэбхукі Supabase ўсе падпісваюць свае нагрузкі. Апрацоўшчык, які не правярае подпіс, — гэта прымітыў запісу ў базу дадзеных для любога зламысніка, які ўгадае URL. Выяўляецца праз форму адказу — непадпісаны запыт, які атрымлівае 200, азначае, што праверка прапушчана.

Як працуе зонтычнае сканаванне BaaS FixVibe

BaaS-фаза FixVibe запускаецца ў тры этапы, кожны з якіх вырабляе розныя знаходкі:

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 — зонды, спецыфічныя для пастаўшчыка. Для кожнага выяўленага пастаўшчыка сканер запускае спецыфічную для пастаўшчыка праверку: baas.supabase-rls зандуе PostgREST; baas.firebase-rules зандуе Firestore + RTDB + Storage; baas.clerk-auth0 валідуе прэфікс ключоў у бандле; праверка bundle-secrets валідуе, што ніякія ўліковыя дадзеныя сэрвіснага ўзроўню не выцяклі. Кожны зонд запускаецца незалежна — знаходка Supabase не блакуе сканаванне Firebase.
3. Этап 3 — крос-пастаўшчыцкая карэляцыя. Сканер крос-спасылаецца на знаходкі. Уцеклы ключ сэрвіснай ролі Supabase разам з адсутным RLS больш сур'ёзны, чым любая знаходка паасобку — справаздача выяўляе гэта. Некалькі пастаўшчыкоў ідэнтыфікацыі (Clerk + Auth0 + карыстальніцкая аўтэнтыфікацыя) у адной праграме — гэта структурная знаходка, пазначаная для агляду.

Кожны зонд пасіўны: максімум адно ананімнае чытанне на рэсурс, з запісанай формай адказу, але змесціва радкоў ніколі не разбіваецца на старонкі і не захоўваецца. Зонды запісу і змены абмежаваны пацверджаным валоданнем даменам — яны ніколі не запускаюцца супраць непацверджаных мэт.

Што знаходзіць сканер на пастаўшчыка

Кожны пастаўшчык BaaS мае розную паверхню і розную стратэгію сканавання. Вось што ахоплена:

• Supabase: адсутны RLS на табліцах, anon-пералічальныя сховішчы, уцеклы JWT service_role або ключ sb_secret_* у бандле, раскрытыя схемы праз ананімны спіс OpenAPI. Гл. Сканер Supabase RLS і Кантрольны спіс сховішча.
• Firebase: правілы if true на Firestore, Realtime Database і Cloud Storage; anon-пералічальныя сховішчы Storage; адсутнае забеспячэнне App Check. Гл. Сканер правіл Firebase і Тлумачальнік правіла if-true.
• Clerk: сакрэтныя ключы sk_* у бандле, pk_test_* у прадакшэне, адсутная праверка подпісу вэбхука, падстаноўныя дазволеныя origin. Гл. Кантрольны спіс Clerk.
• Auth0: кліенцкія сакрэты ў бандле, уключаны грант Implicit, падстаноўныя callback / logout URL, адсутны PKCE на SPA. Гл. Кантрольны спіс Auth0.

Як параўноўваецца сканер BaaS з агульнымі DAST і SAST інструментамі

BaaS-абазнаны сканер выконвае канкрэтную працу, якую не робяць іншыя інструменты. Параўнанне:

Сумленны ахоп: што гэты сканер не замяняе

BaaS-абазнаны DAST-сканер — гэта мэтавы інструмент, а не поўная праграма бяспекі. Ён не:

• Замяняе SAST або SCA. Статычны аналіз знаходзіць CVE залежнасцей (Snyk, Semgrep) і ўразлівасці ўзроўню кода (SonarQube), якія DAST-сканер не можа. Запускайце абодва.
• Замяняе ручное тэставанне на пранікненне. Чалавек-пентэстэр знаходзіць заганы бізнес-логікі, межавыя выпадкі аўтарызацыі і ланцужковыя ўразлівасці, якія ніякі сканер не можа. Найміце пентэстэра перад буйным запускам або аўдытам адпаведнасці.
• Праводзіць аўдыт вашага кода або рэпазіторыя на сакрэты ў гісторыі git. Праверка bundle-secrets ахоплівае тое, што цяпер разгорнута, а не тое, што было гістарычна закаміцена. Выкарыстоўвайце git-secrets або gitleaks для гігіены рэпазіторыя.
• Ахоплівае не-BaaS бэкэнд-сэрвісы. Калі ваша праграма выкарыстоўвае карыстальніцкі бэкэнд (Express, Rails, Django, FastAPI), FixVibe сканіруе яго HTTP-паверхню, але не зандуе базу дадзеных або інфраструктуру за ёй. Гэта тэрыторыя агульнага DAST + SAST.

Часта задаваныя пытанні

Наступныя крокі

Запусціце бясплатнае сканаванне FixVibe супраць вашага прадукцыйнага URL — праверкі BaaS-фазы пастаўляюцца на кожным тарыфе, у тым ліку на бясплатным. Для глыбокіх паглыбленняў, спецыфічных для пастаўшчыка, асобныя артыкулы ў гэтым раздзеле дэталёва ахопліваюць кожнага пастаўшчыка: Supabase RLS, Раскрыццё сэрвіснага ключа Supabase, Сховішча Supabase, Правілы Firebase, Firebase if-true, Clerk і Auth0.