Day 18：一個弱點，從「修好了」到「根本不在 header 上」

昨天那份地圖裡的第一組——安全標頭與弱點判定——今天走完整條線。這篇的起點很單純：一份弱掃報告上的點擊劫持弱點，我拿 curl 打出回應標頭，問 AI「這樣算修好了嗎」。但這個問題一路被我自己往下追，最後追到一個跟 header 完全無關、而且真的會外洩個資的地方。

這也是資安篇第一次完整示範昨天講的那套分工：AI 提供判讀，我用手上的業務事實反駁，一來一往把問題定位到對的地方。

第一步：這算修好了嗎

弱掃報告上有一條「點擊劫持：CSP frame-ancestors 缺失」。我拿 curl -I 打正式站，把回應標頭整段貼給 AI。標頭裡確實有 frame-ancestors 'self'，AI 判定「✅ 可以滿足修正要求」，順帶提醒我幾個無傷大雅的小地方：X-Frame-Options 重複出現、Referrer-Policy 設了三次值還互相打架，依規範最後一個生效。

我補打了一次登入頁的完整 CSP（帶 nonce 的那份），AI 一樣判「已修正、可通過驗收」，另外多提了一句值得記的：這個端點回的是 302 轉址，建議確認轉址目標頁面是不是也帶著同樣的 CSP，別只有入口有、真正的頁面沒有。這一步是最單純的弱點判定——報告說缺什麼，看回應裡有沒有，有就結案。判讀正確，沒有爭議。

但接下來我丟了一個完全不同性質的東西。

第二步：AI 看錯了對象

我手上有一支 shell script，內容是先用 curl 取得網站的 cookie 和 token，再帶著這組憑證直接對查詢 API 發 POST、用空條件把資料撈出來。我問：現在這組 header 配置，擋得住這種行為嗎？

AI 第一次回答分析錯了對象——那支腳本裡示範攻擊的是另一個系統，AI 就把那個系統當成分析主體，得出「header 對那個系統無效，但問題不在這裡」的結論。我把問題重講一次：我要問的是這個網站自己碰到同一種手法會怎樣。

AI 重新評估，這次答案很乾脆：frame-ancestors、X-Frame-Options、CSP 所有指令、SameSite、HttpOnly、HSTS、CORS——全部無效。理由一致：這些防護規範的對象是瀏覽器行為，而 curl 不是瀏覽器。它自己維護 cookie jar、自己組 header，該帶的憑證都帶得上，卻沒有任何一條瀏覽器規則能約束它。這正是昨天那個「header 只規範瀏覽器，但攻擊者用 curl」的質疑，在真實案例上的答案。

第三步：AI 開了一張防禦清單，被我一條條打回去

AI 接著提了一輪標準防禦建議：限制來源 IP、強制登入驗證、rate limiting、User-Agent 檢查、MFA。

這些建議本身都對，但都不適合我的處境。我一條條回：這是對外公開的查詢網站，一般民眾本來就該能匿名查，限制 IP 跟強制登入直接排除；這個案例不是高頻攻擊，rate limiting 擋不到；User-Agent、Referer 這種東西 curl 要偽造太簡單，不構成防線；而且查的資料本身也不算敏感。我把這幾點丟回去，問：你提的方案好像全部不可行，還有別的做法嗎？

這一輪反駁，是這篇的轉折。它靠的不是資安知識——AI 那張清單在資安教科書上完全正確——靠的是只有我知道的業務事實：這是公開查詢站、查詢頻率不高、資料非敏感。AI 沒有這些脈絡，只能給最泛用、最保守的答案；把這些答案收斂到「哪個真的能用」，是我的活。

AI 被逼到這裡，誠實地退了一步：承認前面的方案大多不適用，重新定位問題——這根本不是 header 能解決的弱點。真正的破口在那個空的查詢條件，允許 {} 直接回傳全部，這是「過度資料揭露」，不是點擊劫持也不是 CSRF。它甚至老實列出「風險接受」這個選項：如果資料本來就可公開，技術上擋不掉這件事本身就不算弱點。

第四步：我丟出截圖，真正的洞才現形

到這裡看似收斂了，但我知道還有一層沒講。我把根本原因講白：問題在「允許空白條件」加上「CAPTCHA 失能」——畫面上明明有驗證碼欄位，但那支腳本只抓了 token 就直接送，完全沒帶驗證碼，一樣拿到資料。我附上截圖。

看到截圖後，AI 的分析才真正落地：查詢頁確實有驗證碼欄位，但後端 API 完全不檢查——前端有、後端不驗，這是典型的「前端驗證、後端不驗」。它整理出三個站得住腳的弱點：CAPTCHA 後端未驗證、空條件回傳全部、敏感個資可被程式化擷取。

第五步：AI 又武斷了一次，我再打回去

但 AI 在這輪分析裡多加了一條：它注意到前端程式碼有兩行被註解掉的測試用查詢參數（開發時期留的預填值），把這個也算成一項「查詢邏輯外洩在前端」的弱點。

我又把這條打回去：那只是 AngularJS 標準的雙向綁定，前端收參數、打包成 JSON 送後端查詢，跟「查詢邏輯在前端」是兩回事；那兩行註解只是開發時期忘了清的測試值，SPA 的前端程式碼本來就看得到，這不構成弱點。

AI 收回了這條：「你說得對，這點我確實武斷了。」弱點清單收斂回三項。這是同一篇裡 AI 第二次過度延伸——第一次是套用制式防禦清單，第二次是把正常的前端寫法錯判成弱點。兩次都是同一個模式：在缺業務脈絡時，AI 傾向把任何看起來可疑的東西都算進弱點，而把清單收斂到真正成立的項目，靠的是人手上的判斷。

第六步：最後兩個細節，遮罩做在哪、哪些才是個資

我補了第四點：回傳資料要遮罩。AI 這次講對了一個關鍵原則——遮罩一定要做在後端。因為 curl 打的是 API、拿的是後端原始 JSON，根本不經過前端渲染；如果遮罩只做在前端，curl 照樣拿到完整明文，等於沒做。這一步 AI 沒犯錯，反而把「別重蹈 CAPTCHA 覆轍」這個類比講得很到位。

但它列遮罩欄位時又多算了。它把查詢輸入欄位（身分證、電話）也列進回傳結果要遮的清單。我糾正：畫面上回傳的四個欄位其實是案件編號、一碼通、起造人、地址，並沒有身分證；真正算個資、需要遮的只有起造人姓名和地址門牌這兩項，案件編號跟一碼通是識別碼，遮了反而失去查詢意義。AI 修正了範圍。

這一天的分工

這篇從頭到尾沒有一次是 AI 在資安知識上出錯——它對 header 作用範圍的判斷、對「前端驗證後端不驗」的辨識、對「遮罩要做在後端」的原則，全部正確。它出錯的地方，都是過度延伸的判定：套一份放諸四海皆準的防禦清單、把正常前端寫法當弱點、把輸入欄位當成要遮的回傳欄位。這三次都是同一件事——AI 在沒有業務脈絡時，會往「最保守、最全面」的方向鋪，而不是往「這個具體系統實際需要什麼」收。

我在這篇裡沒有貢獻任何一條資安知識，我貢獻的全是業務事實：這是公開查詢站、頻率不高、這行是舊測試碼、這欄不是個資。但正是這些事實，把一個掛著「點擊劫持」標籤、看起來用 header 就能結案的弱點，一路追到「CAPTCHA 後端沒驗、空條件撈全部、個資沒遮」這三個真正的洞。這就是昨天講的那條線的第一次完整演練：知識可以外包給 AI，但判斷這些知識適不適用於眼前這個系統，不行。

明天換一種輸入：不是弱掃報告，是一份滲透測試報告——當報告聲稱「破解了系統的 JWT」時，那到底是真的被破解，還是報告自己看錯了。