今年2月，OpenAI前創(chuàng)始成員Andrej Karpathy憑一己之力，帶火了一個(gè)詞——“氛圍編碼”（Vibe Coding）。
簡(jiǎn)單說，就是“你說想法，AI寫代碼”。就算完全不懂編程，只要有個(gè)點(diǎn)子，借助像Cursor、ChatGPT這樣的AI工具，也能快速做出一個(gè)應(yīng)用、小游戲之類的。這種“說著就能寫程序”的方式吸引了不少開發(fā)者嘗試。
不過，看起來(lái)輕松高效的背后，也藏著不小的安全隱患。并不是每個(gè)人、每個(gè)項(xiàng)目都適合靠“氛圍”上代碼。
這不，一位開發(fā)者Harley Kimball就在X上分享了自己使用“氛圍編碼”而后“掉坑”的經(jīng)歷。他用了三天不到的時(shí)間開發(fā)并上線了一個(gè)聚合網(wǎng)站的應(yīng)用，殊不知，卻在隨后短短兩天內(nèi)接連遭遇兩次安全漏洞攻擊。
幸運(yùn)的是，這兩次攻擊都由白帽黑客（負(fù)責(zé)任的安全研究員）在沒有惡意破壞的前提下發(fā)現(xiàn)并反饋。為此，Harley Kimball將自己的遭遇進(jìn)行了總結(jié)與復(fù)盤，希望為更多的初創(chuàng)項(xiàng)目和個(gè)人開發(fā)者敲響警鐘。
三天快速開發(fā)的網(wǎng)站
Harley Kimball做的這個(gè)應(yīng)用，說白了就是一個(gè)把各大安全研究員平臺(tái)（像HackerOne、Bugcrowd、GitHub這些）上的公開資料集中到一塊的網(wǎng)站。用戶注冊(cè)登錄之后，可以一眼看到各路白帽黑客的公開檔案。
Kimball的初衷，是想給整個(gè)漏洞賞金圈搞一個(gè)“查號(hào)寶典”，方便大家快速找到相關(guān)研究員的資料。
據(jù)Kimball自述，這款目錄網(wǎng)站的前端是通過Cursor和Lovable等AI編程工具搭建的，并與Supabase提供的云數(shù)據(jù)庫(kù)服務(wù)相連。Supabase在開發(fā)者中頗受歡迎，提供開箱即用的認(rèn)證、存儲(chǔ)和數(shù)據(jù)庫(kù)功能。
不過，整個(gè)系統(tǒng)中最關(guān)鍵的數(shù)據(jù)采集部分——也就是把各個(gè)平臺(tái)的公開資料導(dǎo)入數(shù)據(jù)庫(kù)的過程——是通過獨(dú)立的自動(dòng)化腳本來(lái)完成的，并沒有集成在前端或用戶操作中。這種“前后分離”的設(shè)計(jì)，雖然能讓界面更輕便，也便于快速上線，但也意味著如果底層權(quán)限控制沒做好，系統(tǒng)可能在開發(fā)者都沒注意到的地方暴露風(fēng)險(xiǎn)。
起初，Harley Kimball打算讓用戶使用Supabase Auth自行注冊(cè)，并提交他們想要匯總的個(gè)人資料。但在開發(fā)過程中，他意識(shí)到，處理用戶注冊(cè)不僅涉及身份驗(yàn)證（Authentication），還涉及權(quán)限管理（Authorization）——如果管理不當(dāng)，可能造成數(shù)據(jù)被惡意篡改。
因此，他放棄了自助注冊(cè)功能，轉(zhuǎn)而采用只讀的數(shù)據(jù)視圖...令他沒想到的是，這也成為了第一個(gè)安全漏洞的導(dǎo)火索。
第一次被攻破：郵箱泄露引發(fā)的權(quán)限繞過
在開發(fā)測(cè)試階段，Kimball采用Supabase提供的用戶認(rèn)證功能，這意味著用戶必須使用真實(shí)郵箱注冊(cè)登錄。
然而，他在檢查前后端的數(shù)據(jù)傳輸時(shí)意外發(fā)現(xiàn)：用戶郵箱信息會(huì)被一并返回給前端頁(yè)面，存在泄露風(fēng)險(xiǎn)。雖然這些郵箱可能原本是公開的，但一旦用戶對(duì)平臺(tái)抱有隱私期待，這種行為就可能構(gòu)成嚴(yán)重的問題。
為了修復(fù)這個(gè)漏洞，他采用了一個(gè)常見的處理方式：用PostgreSQL創(chuàng)建了一個(gè)“視圖”（view），只提取所需字段，排除了郵箱信息，并讓前端只訪問這個(gè)視圖。表面上看，這個(gè)做法更安全了——然而，問題也悄然埋下。
正式上線后不久，也就是在第一個(gè)版本發(fā)布不到24小時(shí)，一位安全研究員反饋稱：盡管網(wǎng)站的前端并沒有提供新增或修改數(shù)據(jù)的入口，他依然能在數(shù)據(jù)庫(kù)中隨意插入、修改和刪除記錄。這顯然說明，系統(tǒng)的訪問權(quán)限控制出了問題。
問題的根源，出在那個(gè)看似“安全”的數(shù)據(jù)庫(kù)視圖上。
Kimball在創(chuàng)建視圖時(shí)，使用的是默認(rèn)設(shè)置——也就是說，這個(gè)視圖運(yùn)行時(shí)會(huì)繼承其創(chuàng)建者（也就是管理員）的權(quán)限。而PostgreSQL的行級(jí)安全（Row-Level Security,RLS）機(jī)制，是需要額外配置才能在視圖中生效的。如果沒有手動(dòng)啟用“SECURITY INVOKER”或加上專門的安全限制，RLS就會(huì)被繞過，導(dǎo)致權(quán)限失控。
這正是這次“首個(gè)安全漏洞”的核心原因。所幸，一位名為 Goofygiraffe06的研究員負(fù)責(zé)任地報(bào)告了這個(gè)問題，Kimball隨后緊急修復(fù)了訪問權(quán)限，重新設(shè)計(jì)了數(shù)據(jù)的查詢方式，堵上了這個(gè)漏洞。
第二次被攻破：關(guān)閉前端不等于關(guān)閉后臺(tái)
就在首個(gè)安全漏洞修復(fù)的第二天，Kimball又收到了另一位安全研究員 Kr1shna4garwal的提醒：攻擊者依舊可以注冊(cè)賬號(hào)并創(chuàng)建數(shù)據(jù)。他們發(fā)現(xiàn)依然可以往數(shù)據(jù)庫(kù)中添加新的“研究員檔案”——雖然不能修改或刪除已有數(shù)據(jù)，但這意味著系統(tǒng)的訪問控制沒有完全鎖死。
這一次的問題，并不是出在前文提到的數(shù)據(jù)庫(kù)視圖上，而是另有隱情。
Kimball雖然在前端界面上取消了“用戶自助注冊(cè)”入口，但后臺(tái)使用的Supabase認(rèn)證服務(wù)（Auth）依舊處于激活啟動(dòng)狀態(tài)。換句話說，攻擊者只要知道API的調(diào)用方式，就可以繞過前端，通過郵箱和密碼注冊(cè)一個(gè)新賬號(hào)，成為系統(tǒng)“眼中”的合法用戶，并按照既有的權(quán)限規(guī)則操作數(shù)據(jù)。
這種“前端沒入口，但后端沒封死”的配置，在不少使用現(xiàn)成后端服務(wù)的項(xiàng)目中很常見，也很容易被忽視。
最終，Kimball通過徹底關(guān)閉Supabase Auth的注冊(cè)功能，才完全堵上了這個(gè)權(quán)限漏洞。
經(jīng)驗(yàn)教訓(xùn)：氛圍編程雖快，安全不能缺位
Kimball在總結(jié)這次“上線即被攻破”的經(jīng)歷時(shí)，也分享了幾點(diǎn)關(guān)鍵反思，對(duì)依賴低代碼或AI工具進(jìn)行開發(fā)的開發(fā)者具有一定參考意義：
首先，“氛圍編碼”（vibe coding）雖然能讓項(xiàng)目快速成型，但默認(rèn)狀態(tài)下往往忽略了安全配置，一不小心就會(huì)留下嚴(yán)重漏洞。
其次，Supabase和PostgreSQL這對(duì)組合功能強(qiáng)大，但它們的權(quán)限模型也相對(duì)復(fù)雜。特別是在使用數(shù)據(jù)庫(kù)視圖（view）和行級(jí)安全策略（Row-Level Security，RLS）時(shí)，如果開發(fā)者不了解其背后的默認(rèn)行為，就很容易配置失誤，導(dǎo)致權(quán)限失控。
比如，PostgreSQL中的視圖默認(rèn)是以創(chuàng)建者（通常是管理員）的權(quán)限運(yùn)行的，這意味著RLS策略會(huì)被繞過，除非顯式指定為SECURITY INVOKER，或另行設(shè)置安全策略。
此外，如果項(xiàng)目并未真正使用Supabase的認(rèn)證功能，務(wù)必在后臺(tái)設(shè)置中徹底關(guān)閉注冊(cè)入口——僅僅在前端頁(yè)面隱藏相關(guān)功能遠(yuǎn)遠(yuǎn)不夠。
Kimball表示，他的應(yīng)用主要聚合的是公開數(shù)據(jù)，因此這兩次安全事件的實(shí)際影響有限。但如果系統(tǒng)涉及的是敏感信息，例如個(gè)人身份數(shù)據(jù)（PII）或健康信息（PHI），類似的配置漏洞可能會(huì)造成災(zāi)難性后果。
這起事件也提醒開發(fā)者，即便是看似簡(jiǎn)單的工具鏈和“只讀數(shù)據(jù)”的項(xiàng)目，也必須進(jìn)行基礎(chǔ)的威脅建模與權(quán)限審查?？焖偕暇€不代表可以省略安全流程，尤其是在AI編碼與自動(dòng)化工具愈發(fā)普及的當(dāng)下。
本文來(lái)源：36氪
文章轉(zhuǎn)載于其他網(wǎng)絡(luò)，如有侵權(quán)請(qǐng)聯(lián)系我們及時(shí)刪除
