🔧 阿川の電商水電行
我的网站被黑了：一天灌入 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 很快給出了程式碼——功能完整、類型正確、能跑。但完全沒有考慮安全性。
而我看到程式碼能跑，就直接部署了。
這不是個例
▲ 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 寫程式碼時踩過安全的坑嗎？評論區聊聊，我來回。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
