Уздзеянне нападніка
Зламыснік можа атрымаць несанкцыянаваны доступ да канфідэнцыяльных дадзеных карыстальніка, змяніць запісы базы дадзеных або захапіць інфраструктуру, выкарыстоўваючы агульныя недагляды ў разгортванні MVP. Сюды ўваходзіць доступ да даных паміж арандатарамі з-за адсутнасці элементаў кантролю доступу [S4] або выкарыстанне ўцечкі ключоў API для паняцця выдаткаў і выкрадання даных з інтэграваных сэрвісаў [S2].
Першапрычына
Спяшаючыся запусціць MVP, распрацоўшчыкі — асабліва тыя, якія выкарыстоўваюць «vibe-кадзіраванне» з дапамогай AI — часта выпускаюць з-пад увагі асноўныя канфігурацыі бяспекі. Асноўнымі прычынамі гэтых уразлівасцяў з'яўляюцца:
- Сакрэтная ўцечка: уліковыя даныя, такія як радкі базы дадзеных або ключы пастаўшчыка AI, выпадкова перададзены ў кантроль версій [S2].
- Парушаны кантроль доступу: прыкладанні не забяспечваюць строгія межы аўтарызацыі, што дазваляе карыстальнікам атрымліваць доступ да рэсурсаў, якія належаць іншым [S4].
- Дазвольныя палітыкі базы даных: у сучасных наладах BaaS (бэкэнд-як-сэрвіс), такіх як Supabase, немагчымасць уключыць і правільна наладзіць бяспеку на ўзроўні радкоў (RLS) пакідае базу дадзеных адкрытай для прамога выкарыстання праз кліенцкія бібліятэкі [S5].
- Слабае кіраванне маркерамі: Няправільнае абыходжанне з маркерамі аўтэнтыфікацыі можа прывесці да захопу сеанса або несанкцыянаванага доступу API да [S3].
Канкрэтныя выпраўленні
Рэалізаваць бяспеку на ўзроўні радка (RLS)
Для прыкладанняў, якія выкарыстоўваюць бэкэнды на аснове Postgres, такія як Supabase, RLS павінны быць уключаны на кожнай табліцы. RLS гарантуе, што сам механізм базы дадзеных забяспечвае абмежаванні доступу, не дазваляючы карыстальніку запытваць даныя іншага карыстальніка, нават калі ў яго ёсць сапраўдны маркер аўтэнтыфікацыі [S5].
Аўтаматызаваць сакрэтнае сканаванне
Інтэгруйце сакрэтнае сканаванне ў працоўны працэс распрацоўкі, каб выяўляць і блакіраваць адпраўку канфідэнцыйных уліковых дадзеных, такіх як ключы API або сертыфікаты [S2]. Калі адбываецца ўцечка сакрэту, яго трэба неадкладна адклікаць і перадаць, бо ён павінен лічыцца скампраметаваным [S2].
Прымяненне строгай практыкі выкарыстання токенаў
Выконвайце галіновыя стандарты бяспекі токенаў, у тым ліку выкарыстанне бяспечных файлаў cookie толькі HTTP для кіравання сеансам і забеспячэнне абмежаванняў адпраўшчыка, дзе гэта магчыма, для прадухілення паўторнага выкарыстання зламыснікамі [S3].
Ужыць агульныя загалоўкі вэб-бяспекі
Пераканайцеся, што ў дадатку прымяняюцца стандартныя меры вэб-бяспекі, такія як Палітыка бяспекі кантэнту (CSP) і бяспечныя транспартныя пратаколы, каб змякчыць распаўсюджаныя атакі на аснове браўзера [S1].
Як FixVibe правярае гэта
FixVibe ужо ахоплівае гэты клас уцечкі даных на некалькіх паверхнях жывога сканавання:
- Supabase RLS уздзеянне:
baas.supabase-rlsздабывае агульнадаступныя пары Supabase URL/неключавы з пакетаў аднолькавага паходжання, пералічвае адкрытыя табліцы PostgREST і выконвае ананімную працу толькі для чытання SELECT правярае, ці адкрыты даныя табліцы. - Прабелы ў рэпазітары RLS:
repo.supabase.missing-rlsразглядае аўтарызаваныя міграцыі SQL рэпазітара GitHub для агульнадаступных табліц, якія ствараюцца без адпаведнай міграцыіALTER TABLE ... ENABLE ROW LEVEL SECURITY. - Палажэнне для захоўвання Supabase:
baas.supabase-security-checklist-backfillпраглядае метаданыя агульнадаступнага сховішча і ананімны доступ да спісаў без загрузкі або змянення даных кліентаў. - Сакрэты і становішча браўзера: сцягі
secrets.js-bundle-sweep,headers.security-headersіheaders.cookie-attributesуцечкі ўліковых даных на баку кліента, адсутнасць загалоўкаў умацавання браўзера і слабыя сцягі аўтэнтыфікацыі файлаў cookie. - Закрытыя зонды кантролю доступу: калі кліент уключае актыўнае сканіраванне і права ўласнасці на дамен правяраецца,
active.idor-walkingіactive.tenant-isolationправяраюць выяўленыя маршруты для экспазіцыі дадзеных паміж рэсурсамі і арандатарамі ў стылі IDOR/BOLA.