我的網站被黑了：一天灌入 227 萬條垃圾數據，AI 寫的代碼差點讓我社死

大家好，我係孟健。

上星期六下晝，我收到一封電郵。

標題好直白：「你啲嘢洩漏咗，兄弟」。

封電郵入面附咗一個暗網論壇連結，聲稱我個網站 kirkify.net 嘅數據庫已經俾人公開下載。

▲ 就係呢封電郵。發件人 punker，連結指向暗網論壇嘅數據庫下載帖

我打開後台一睇——

case_studies 表：227 萬條紀錄。

而前一日，呢張表得 259 條。

由下晝 3 點 25 分開始，持續咗足足 6 個半鐘，有人向我個數據庫度灌咗 227 萬條垃圾數據。

數據分佈好平均：763K approved、763K pending、764K rejected。攻擊者用 FloodUser_XXXXX 嘅命名模式批量寫入，每條 caption 填充 1KB 嘅 base64 隨機數據——呢個唔係隨機攻擊，係有計劃嘅數據庫膨脹攻擊。

▲ 我嘅 AI Agent 墨碼發現數據異常之後嘅應急分析，第一時間定位咗漏洞

漏洞喺邊？一個冇門鎖嘅 API

▲ kirkify.net——我用 AI 編程工具做嘅出海小產品，用 Cursor + Claude 幾日就整好上線咗

問題出喺一個叫 submitCaseStudy 嘅 Next.js Server Action 上面。

呢段代碼有 五個致命問題疊埋一齊：

① Server Action 暴露做 HTTP POST 端點
Next.js 嘅 Server Action 雖然喺服務端執行，但本質上就係一個 HTTP POST 接口。任何人都可以直接構造請求調用，完全唔需要前端頁面。

② 冇認證（No Authentication）
函數體內冇任何 session / auth 驗證。邊個都可以調用，冇門檻。

③ 冇 Rate Limit
冇任何頻率限制。攻擊者寫個循環腳本，每秒可以提交幾百條。

④ 自動審核通過（Auto-Approve）
代碼裏 status: 'approved' 硬編碼，提交就上線。垃圾內容直接喺 Gallery 頁面出現，唔需要任何審核。

⑤ 用 Service Role Key 繞過數據庫安全
代碼用 Supabase 嘅 service_role key 操作數據庫，完全繞過咗行級安全策略（RLS）。雖然數據庫開咗 RLS，但 service_role 有 God Mode 權限，安全策略形同虛設。

五個漏洞疊加嘅效果：你間屋大門打開，冇保安，冇門禁，嚟嘅人自動派 VIP 卡。

而呢段代碼，正正就係 AI 幫我寫嘅。

當初我同 Cursor 講：「幫我寫一個提交案例嘅功能」。AI 好快就俾咗代碼——功能完整、類型正確、行得鬱。但完全冇考慮安全性。

而我見到代碼行得鬱，就直接 deploy 咗。

呢個唔係個別例子

▲ Veracode 2025 報告：測試 100+ 個 AI 模型，45% 嘅代碼引入咗安全漏洞

數據印證咗呢點：

• Veracode 報告
  ：分析 100+ 個 LLM 生成嘅代碼樣本，45% 存在安全漏洞，引入咗 OWASP Top 10 安全問題
• Apiiro 研究
  ：截至 2025 年 6 月，AI 生成代碼每個月引入 超過 10,000 個新安全問題，六個月增長 10 倍
• 常見漏洞類型：缺乏認證、硬編碼密鑰、SQL 注入、缺少輸入校驗、未配置 Rate Limit

AI 好擅長寫「行得鬱嘅代碼」，但佢默認唔會幫你加認證、加速限、配安全策略。

除非你明確要求佢咁做。

修復過程：一日遷移整個數據庫

發現問題之後，我同 AI Agent 墨碼即刻開始修復。

第一步：堵住入口

• 關閉 submitCaseStudy 嘅公開訪問
• 俾所有寫入 API 加上 JWT 認證 + Rate Limit

第二步：全面安全審計

• 審查所有 Server Action 嘅認證狀態
• 檢查 Supabase RLS 配置——發現 case_studies 表雖然開咗 RLS，但得一條 SELECT 策略，冇 INSERT 策略。而代碼用 service_role key 繞過咗全部 RLS
• 檢查 billing_customers、credit_balances 等敏感表——確認冇俾攻擊者訪問，攻擊者只可以透過 Server Action 寫入 case_studies 表

第三步：數據庫遷移（關鍵決策）

• 冇選擇喺原數據庫上修補，而係直接將整個數據庫由 Supabase 遷移到 Cloudflare D1
• 遷移 12 張表，只導入 261 條乾淨數據（260 條 approved + 1 條 pending），227 萬條垃圾數據直接拋棄
• D1 版本完全重寫咗數據訪問層，用 JWT 認證，唔再有裸露嘅 Server Action
• 同步完成 CF Workers 部署，DNS 切換上線

第四步：服務器加固

• fail2ban 收緊（3 次失敗封 24 小時）
• VNC 綁定內網 IP
• 環境變量文件權限改為 600
• 洩漏嘅 API Key 全部輪換

由發現到完成數據庫遷移同埋上線切換，總共用咗大約一日。

俾用 AI 編程嘅你：寫完代碼多問一句

呢次教訓令我養成咗一個習慣：

每次 AI 幫我寫完一個功能，我都會追加一句：

「呢段代碼有咩安全隱患？幫我加上認證、Rate Limit 同輸入校驗。」

就呢一句話，可以避免 80% 嘅安全問題。

再具體啲，每次上線前檢查呢 5 件事：

1. API 端點有冇裸奔？ 唔需要認證就可以訪問嘅寫入 API = 等住俾人刷。特別注意 Next.js Server Action——佢本質係 HTTP POST，唔係「服務端函數」。

2. API Key 有冇硬編碼喺代碼入面？ 檢查 .env 文件權限，確保 Key 唔喺 Git 倉庫入面，更加唔好喺聊天記錄度出現。

3. 數據庫有冇正確配置權限？ 用 Supabase 就開 RLS + 寫好策略。用 service_role key 要非常謹慎——佢可以繞過一切安全策略。

4. 有冇 Rate Limit？ 冇限速嘅 API，就係一個等住俾人刷嘅 API。

5. 有冇監控異常？ 數據量突然增加、請求量突然增加——呢啲信號需要有人睇住。

用 OpenClaw 嘅朋友，多啲留個心眼

最近 OpenClaw 好火（GitHub 21 萬星），越嚟越多人喺自己嘅服務器上面行 AI Agent。

OpenClaw 本身嘅安全性好好——沙箱隔離、權限分級、Token 加密存儲，呢啲基礎設施層面做得紮實。但你用 OpenClaw 搭建嘅應用同服務，安全性取決於你自己。

呢次俾人攻擊之後，我將自己服務器上面嘅安全配置全部過咗一次，總結咗幾條實用建議：

1. .env 文件權限改 600

你嘅 OpenClaw 配置文件同環境變量入面存咗所有 API Key。執行 chmod 600 ~/.openclaw/*.json 和 chmod 600 .env，只允許當前用戶讀寫。

2. 唔好喺聊天入面發明文 Key

我呢次就踩咗呢個坑——喺 Telegram 入面俾 Agent 發咗 Replicate API Key，結果俾記錄咗喺幾十個檔案入面。正確做法係直接寫入 .env 或用 openclaw config 設置。

3. 遠程訪問綁內網

如果你喺服務器上面行 VNC、遠程桌面或者調試端口，一定綁到內網 IP 或者 Tailscale 網絡，唔好暴露喺公網。我之前 VNC 綁咗 0.0.0.0，等於全世界都可以連。

4. 開 fail2ban

SSH 暴力破解係最常見嘅攻擊手段。apt install fail2ban 一行命令，建議配置 3 次失敗封 24 小時。

5. Agent 唔好用 root 行

俾 OpenClaw 創建專用用戶，限制文件系統訪問範圍。萬一 Agent 俾人誘導執行惡意命令，損害範圍可控。

6. 定期檢查開放端口

運行 ss -tlnp 睇嚇你個服務器對外暴露咗邊啲端口。數據庫端口（5432、3306）、調試端口（9229、18800）絕對唔應該對公網開放。

OpenClaw 俾咗你 10 倍嘅生產力，亦都意味住 10 倍嘅攻擊面。Agent 可以幫你寫代碼、調接口、操作數據庫——如果權限冇控制好，攻擊者都可以透過 Agent 做呢啲嘢。

AI 編程令我哋 10 倍速出貨，但亦都令安全債務 10 倍速累積。

代碼行得鬱，唔代表代碼安全。

希望你唔使我咁樣，等到收到黑客電郵嗰日先明白呢個道理。

你用 AI 寫代碼時有冇踩過安全嘅坑？留言區傾嚇，我嚟覆。

📚 精選文章推薦

大家好，我是孟健。

上週六下午，我收到一封郵件。

標題很直白："你的東西泄露了，兄弟"。

郵件裏附了一個暗網論壇連結，聲稱我的網站 kirkify.net 的數據庫已經被公開下載。

▲ 就是這封郵件。發件人 punker，連結指向暗網論壇的數據庫下載帖

我打開後台一看——

case_studies 表：227 萬條記錄。

而前一天，這張表只有 259 條。

從下午 3 點 25 分開始，持續了整整 6 個半小時，有人往我的數據庫裏灌了 227 萬條垃圾數據。

數據分佈極其均勻：763K approved、763K pending、764K rejected。攻擊者用 FloodUser_XXXXX 的命名模式批量寫入，每條 caption 填充 1KB 的 base64 隨機數據——這不是隨機攻擊，是有計劃的數據庫膨脹攻擊。

▲ 我的 AI Agent 墨碼發現數據異常後的應急分析，第一時間定位到了漏洞

漏洞在哪？一個沒有門鎖的 API

▲ kirkify.net——我用 AI 編程工具做的出海小產品，用 Cursor + Claude 幾天搭好就上線了

問題出在一個叫 submitCaseStudy 的 Next.js Server Action 上。

這段代碼有 五個致命問題疊在一起：

① Server Action 暴露為 HTTP POST 端點
Next.js 的 Server Action 雖然在服務端執行，但本質上就是一個 HTTP POST 接口。任何人都可以直接構造請求調用，完全不需要前端頁面。

② 無認證（No Authentication）
函數體內沒有任何 session / auth 驗證。誰都能調，無門檻。

③ 無 Rate Limit
沒有任何頻率限制。攻擊者寫個循環腳本，每秒能提交幾百條。

④ 自動審核通過（Auto-Approve）
代碼裏 status: 'approved' 硬編碼，提交即上線。垃圾內容直接出現在 Gallery 頁面，不需要任何審核。

⑤ 用 Service Role Key 繞過數據庫安全
代碼用 Supabase 的 service_role key 操作數據庫，完全繞過了行級安全策略（RLS）。雖然數據庫開了 RLS，但 service_role 擁有 God Mode 權限，安全策略形同虛設。

五個漏洞疊加的效果：你家大門敞開，沒有保安，沒有門禁，來者自動發 VIP 卡。

而這段代碼，恰恰是 AI 幫我寫的。

當初我對 Cursor 說："幫我寫一個提交案例的功能"。AI 很快給出了代碼——功能完整、類型正確、能跑。但完全沒有考慮安全性。

而我看到代碼能跑，就直接部署了。

這不是個例

▲ Veracode 2025 報告：測試 100+ 個 AI 模型，45% 的代碼引入了安全漏洞

數據印證了這一點：

• Veracode 報告
  ：分析 100+ 個 LLM 生成的代碼樣本，45% 存在安全漏洞，引入了 OWASP Top 10 安全問題
• Apiiro 研究
  ：截至 2025 年 6 月，AI 生成代碼每月引入 超過 10,000 個新安全問題，六個月增長 10 倍
• 常見漏洞類型：缺乏認證、硬編碼密鑰、SQL 注入、缺少輸入校驗、未配置 Rate Limit

AI 很擅長寫"能跑的代碼"，但它默認不會幫你加認證、加限速、配安全策略。

除非你明確要求它這麼做。

修復過程：一天遷移整個數據庫

發現問題後，我和 AI Agent 墨碼立刻開始修復。

第一步：堵住入口

• 關閉 submitCaseStudy 的公開訪問
• 給所有寫入 API 加上 JWT 認證 + Rate Limit

第二步：全面安全審計

• 審查所有 Server Action 的認證狀態
• 檢查 Supabase RLS 配置——發現 case_studies 表雖然開了 RLS，但只有一條 SELECT 策略，沒有 INSERT 策略。而代碼用 service_role key 繞過了全部 RLS
• 檢查 billing_customers、credit_balances 等敏感表——確認未被攻擊者訪問，攻擊者只能通過 Server Action 寫入 case_studies 表

第三步：數據庫遷移（關鍵決策）

• 沒有選擇在原數據庫上修補，而是直接把整個數據庫從 Supabase 遷移到 Cloudflare D1
• 遷移 12 張表，只導入 261 條幹淨數據（260 條 approved + 1 條 pending），227 萬條垃圾數據直接拋棄
• D1 版本完全重寫了數據訪問層，用 JWT 認證，不再有裸露的 Server Action
• 同步完成 CF Workers 部署，DNS 切換上線

第四步：服務器加固

• fail2ban 收緊（3 次失敗封 24 小時）
• VNC 綁定內網 IP
• 環境變量文件權限改為 600
• 泄露的 API Key 全部輪換

從發現到完成數據庫遷移和上線切換，總共花了約一天。

給用 AI 編程的你：寫完代碼多問一句

這次教訓讓我養成了一個習慣：

每次 AI 幫我寫完一個功能，我都會追加一句：

"這段代碼有什麼安全隱患？幫我加上認證、Rate Limit 和輸入校驗。"

就這一句話，能避免 80% 的安全問題。

再具體一點，每次上線前檢查這 5 件事：

1. API 端點有沒有裸奔？ 不需要認證就能訪問的寫入 API = 等着被刷。特別注意 Next.js Server Action——它本質是 HTTP POST，不是"服務端函數"。

2. API Key 有沒有硬編碼在代碼裏？ 檢查 .env 文件權限，確保 Key 不在 Git 倉庫裏，更不要出現在聊天記錄裏。

3. 數據庫有沒有正確配置權限？ 用 Supabase 就開 RLS + 寫好策略。用 service_role key 要極其謹慎——它能繞過一切安全策略。

4. 有沒有 Rate Limit？ 沒有限速的 API，就是一個等着被刷的 API。

5. 有沒有監控異常？ 數據量突增、請求量突增——這些信號需要有人盯着。

用 OpenClaw 的朋友，多留個心眼

最近 OpenClaw 火了（GitHub 21 萬星），越來越多人在自己的服務器上跑 AI Agent。

OpenClaw 本身的安全性很好——沙箱隔離、權限分級、Token 加密存儲，這些基礎設施層面做得紮實。但你用 OpenClaw 搭建的應用和服務，安全性取決於你自己。

這次被攻擊之後，我把自己服務器上的安全配置全過了一遍，總結了幾條實用建議：

1. .env 文件權限改 600

你的 OpenClaw 配置文件和環境變量裏存着所有 API Key。運行 chmod 600 ~/.openclaw/*.json 和 chmod 600 .env，只允許當前用戶讀寫。

2. 不要在聊天裏發明文 Key

我這次就踩了這個坑——在 Telegram 裏給 Agent 發了 Replicate API Key，結果被記錄到了幾十個文件裏。正確做法是直接寫進 .env 或用 openclaw config 設置。

3. 遠程訪問綁內網

如果你在服務器上跑 VNC、遠程桌面或調試端口，一定綁到內網 IP 或 Tailscale 網絡，不要暴露在公網。我之前 VNC 綁了 0.0.0.0，相當於全世界都能連。

4. 開 fail2ban

SSH 暴力破解是最常見的攻擊手段。apt install fail2ban 一行命令，建議配置 3 次失敗封 24 小時。

5. Agent 不要用 root 跑

給 OpenClaw 創建專用用戶，限制文件系統訪問範圍。萬一 Agent 被誘導執行惡意命令，損害範圍可控。

6. 定期檢查開放端口

運行 ss -tlnp 看看你的服務器對外暴露了哪些端口。數據庫端口（5432、3306）、調試端口（9229、18800）絕對不應該對公網開放。

OpenClaw 給了你 10 倍的生產力，也意味着 10 倍的攻擊面。Agent 能幫你寫代碼、調接口、操作數據庫——如果權限沒控好，攻擊者也能通過 Agent 做這些事。

AI 編程讓我們 10 倍速出活，但也讓安全債務 10 倍速累積。

代碼能跑，不代表代碼安全。

希望你不用像我一樣，等到收到黑客郵件那天才明白這個道理。

你用 AI 寫代碼時踩過安全的坑嗎？評論區聊聊，我來回。

📚 精選文章推薦