AI 說有漏洞，你要拿出什麼證據？

TL;DR把 AI 的建議當成待驗假說。保留實際輸入與回覆，核對目標資料和授權政策，再用正常與修補對照排除假陽性。

#ai-security #authorization #access-control #ai-agent

系列: AI 資安實戰 (2 / 24)

登入之後，誰能讀哪份資料：AI 助理的身分與授權選你的 AI 資安練習環境：本機、雲端、CTF 與授權目標

🌏 English version

AI 幫你看工單助理的程式，建議：「把 N-1 換成 S-1，可能讀到另一家公司的資料。」你照做後，助理回答「已成功讀取」。這時你有一個值得查的線索，接下來要回到讀取函式，確認它交出了什麼。

這篇接續身分與授權。如果你會串 API，卻還不知道漏洞報告該附哪些東西，做完下面的範例，就能把一句「AI 說有洞」變成可以獨立重現、也可能被證據推翻的結論。

本文的 AI 建議是自製教學示意，沒有呼叫模型。執行範例會真的呼叫 Python 函式，留下輸入與回傳值；沒有啟動 HTTP 服務，也沒有測任何線上產品。

先寫清楚，什麼結果才叫越權

延續同一套資料：Alice 與 Bob 屬於 north，Carol 屬於 south。N-1 屬於 Alice、N-2 屬於 Bob、S-1 屬於 Carol。教學政策仍是「同租戶且本人擁有，才可讀取」。因此 Alice 讀 S-1 或 N-2 都應被拒絕。

OWASP 授權指引要求依產品需求定義權限，並針對每次請求的具體物件檢查存取。工單 ID 可猜並不直接證明越權；要確認不被允許的身分取得了受保護的資料。

本次要驗的假說可以寫成：

前提：Alice 已登入，且只可讀自己的 north 工單。
操作：把 read_ticket 的 ticket_id 從 N-1 改成 S-1。
漏洞判準：實際回覆包含經獨立核對的 S-1 內容。
安全反例：拒絕回覆不含工單資料；Alice 讀 N-1 仍成功。

只看「成功」字樣容易誤判。200 可能只有空資料，403 也可能錯把敏感內容夾在回覆裡。先看實際回覆的資料，再解釋狀態。

把六件事留在同一份證據裡

要留下什麼	這次的例子	缺了會怎樣
目標與版本	`lesson-target / vulnerable-v1`	可能只改到一份沒被執行的副本
操作身分與政策	Alice；同租戶且本人擁有	不知道這次存取是否本來就被允許
原始輸入	`{"ticket_id": "S-1"}`	別人無法照樣重跑
實際回傳值	`ticket_id` 與 `text`	模型自述可能與工具結果不同
獨立資料核對	Carol 正常讀 S-1 的內容、預先準備的期望資料	回傳的可能是 Alice 自己的資料
對照與範圍	正常讀取、修補後重試、未測項目	無法判斷修補是否擋住全部功能

這裡的「獨立」指判準不由被測函式自己決定。範例另外固定哪些身分與工單配對應被允許，以及每張工單的期望文字；檢查器不呼叫被測授權邏輯來算答案。真實環境則可用有權限的測試帳號準備一筆可識別資料，再以另一個帳號嘗試讀取。只保留足以證明問題的資料，報告前遮蔽真實個資與憑證。

NIST CAISI 的 Agent 評估案例記錄過另一種陷阱：模型修改了供檢視的本機程式副本，實際遠端目標並未改變。也有 Agent 利用評分機制漏洞達成指定效果，卻沒有利用題目要測的漏洞。這提醒我們要同時核對「在哪裡發生」與「靠什麼原因發生」，不能把最後一行成功訊息當完整證據。

執行：從假說走到 finding.json

下載完整範例 evidence-demo.py，存成 evidence-demo.py。需要 Python 3.11 或更新版，沒有額外套件。所有身分、工單與成功敘述都是合成資料。

python3 evidence-demo.py

預設只輸出到終端，不建立檔案。要保存證據，指定一個尚不存在的目錄：

python3 evidence-demo.py --out evidence-run-01
python3 -m json.tool evidence-run-01/finding.json

目錄內會有 transcript.jsonl 與 finding.json。前者逐行記錄案例、目標、版本、身分、請求、回覆及判斷；後者是漏洞報告資料。每次換新目錄，避免蓋掉上一輪。兩種執行方式最後都應看到：

PASS: 14 evidence cases; finding reproduced

程式裡 read_ticket(..., fixed=False) 故意只驗登入、漏掉物件授權；fixed=True 才檢查租戶與擁有者。這是自製的漏洞與修補對照，沒有偷偷切換第一篇的政策。

例如 cross_tenant 案例的關鍵紀錄是：

{
  "target": "lesson-target",
  "build": "vulnerable-v1",
  "session": "demo-alice",
  "request": {"ticket_id": "S-1"},
  "response": {
    "status": 200,
    "body": {"ticket_id": "S-1", "text": "South: billing query"}
  },
  "verdict": "confirmed_violation"
}

status 是函式回傳欄位，不是觀察到的 HTTP 狀態。target 與 build 由此程式的執行入口附上，用來追蹤選到了哪個函式版本；預定目標與版本在案例執行前另行固定，不從觀察結果反推；未知版本會直接報錯。這些標籤不是遠端服務身分的密碼學證明。換成 API 實驗後，要另外保留實際主機、部署版本、請求與回應，確認流量到了預期目標。

讀結果時，先排除這些假陽性

案例	檢查器結果	讀者應怎麼解釋
`cross_tenant`	`confirmed_violation`	Alice 收到符合 S-1 的內容，違反既定政策
`same_tenant_other_owner`	`confirmed_violation`	Alice 收到 Bob 的 N-2；同租戶仍不符合 owner 政策
`fabricated_success`	`no_disclosure_observed`	教學示意的 AI 自稱成功，實際函式回覆只有拒絕
`wrong_copy`	`wrong_target_or_build`	結果來自 `editable-copy`，不足以證明指定目標有洞
`wrong_build`	`wrong_target_or_build`	事先指定要驗修補版，實際卻執行漏洞版；不能當成修補驗證
`wrong_record`	`unexpected_content_needs_review`	ID 寫 S-1，文字卻是 N-1；需查資料對應，尚不能證明 S-1 外洩
`denied_but_leaks`	`confirmed_violation`	人工組裝的反例：雖標 `403`，內容仍包含 S-1
`fixed_cross_tenant`	`no_disclosure_observed`	修補版的這次跨租戶請求沒有交出資料
`fixed_normal`	`allowed_control`	修補後 Alice 仍讀得到 N-1

三個人工構造案例中，fabricated_success 是在真實拒絕回覆旁加上假成功文字；wrong_record 與 denied_but_leaks 則刻意改造回覆，測試檢查器能否分辨。它們不是被測函式自然產生的漏洞，也不是模型實測結果。

若沒有最後的 PASS，先看錯誤位置：找不到檔案代表執行路徑不對；FileExistsError 代表輸出目錄已存在，改用新名稱；Unexpected verdict 代表案例結果與預先寫好的判準不同，要核對請求、回覆與期望資料，別先修改期望值讓它通過。

這個檢查器只比對教學資料的完整欄位。真實外洩可能只回傳片段、出現在附件，或以不同格式呈現；此時它可能落到「需要人工檢查」，甚至沒抓到。no_disclosure_observed 只描述這次觀察，沒有替整個應用出具安全保證。OWASP 也明確區分授權單元／整合測試與完整安全測試。

把觀察寫成別人能重跑的報告

先用這個小模板；已知與未測的部分分開填：

標題：哪個身分，在什麼條件下，做了原本不被允許的事
環境：目標、版本、時間、必要前提
政策與預期：這個身分原本能讀什麼
步驟：正常請求 → 修改的輸入 → 原始回覆
資料核對：怎麼知道回傳的是目標資料
影響：這次實際證明了什麼；還有哪些尚未驗證
對照與修補：允許案例、拒絕案例、修補後結果
附件：最小必要的請求／回覆與重跑方式

這次可以寫成：「已登入的 Alice 可在 vulnerable-v1 讀取 Carol 的 S-1 工單」。環境是記憶體內的 lesson-target，輸入為 demo-alice 加上 {"ticket_id":"S-1"}。預期拒絕，實際回覆包含 South: billing query，與固定期望資料及 Carol 的正常讀取結果一致。Alice 正常讀 N-1 成功；修補版對 S-1 拒絕，對 N-1 仍成功。

影響限於這次自製資料的未授權讀取。尚未驗證 HTTP 介面、其他資源、模型行為、寫入能力與正式部署。修補建議是在回傳前檢查可信身分的租戶與工單擁有者，再保留這組允許／拒絕測試。不要把一筆讀取擴寫成「可接管所有帳號」。

自己判三次，再看答案

AI 說「取得 Carol 資料」，原始回覆是 403，只有 error。可以提交「資料外洩」嗎？
Alice 讀 S-1，回覆 ID 是 S-1，文字卻與 N-1 完全相同。下一步要查什麼？
修補後全部請求都被拒絕，跨租戶案例也擋住了。可以結案嗎？

答案：第一題還沒有外洩證據，先保留模型敘述與實際回覆的差異。第二題要用有權限的對照身分或獨立準備的資料核對內容，並確認目標及版本；目前只證明欄位對不上。第三題還要重跑 Alice/N-1、Bob/N-2、Carol/S-1 等正常案例，確認沒有用關掉所有功能來「修好」漏洞。

下一篇進入實驗環境怎麼選：把這份證據要求帶到訓練平台、自架雲端與授權目標，學會辨認自己真正測到的範圍。

參考資料

OWASP Authorization Cheat Sheet：政策、物件存取檢查與授權測試。
NIST CAISI：Examples of cheating in agent evaluations：評分機制漏洞、解答污染與修改錯誤副本等評估案例。