攻擊維度地圖：系統有哪些面可以打

攻擊維度地圖：系統有哪些面可以打 逆向思維告訴你「要弄壞它」，但弄壞的方向有很多——你從哪裡下手？如果每次都靠直覺，測到的永遠是同一塊，漏掉的永遠是同一塊。有張地圖會好很多。 一張維度地圖 有個好記的口訣，幫你把六個可以攻擊的維度記起來：「結功資、平操時」。展開來說： 結構 ：程式碼與架構層——記憶體洩漏、API 版本相容、第三方依賴的穩定性。 功能 ：每個功能本身的邊界——最大值、最小值、空值、零值。 資料 ：輸入與儲存的資料型態——格式異常、超長字串、注入字串、小數精度。 平台 ：執行環境——不同 OS、瀏覽器、螢幕尺寸、系統語言、網路品質。 操作 ：使用者的操作序列——跳步驟、快速重複觸發、非預期的上一頁。 時間 ：與時序有關的問題——併發、超時、系統時鐘偏移、跨越午夜或跨月。 每次拿到一個功能，把這六個維度掃一遍，就不容易留死角。 瘋狂操作（連點 / 狂刷） 最直覺的攻擊：在按鈕上狂點。 拿「送出訂單」為例：連點 20 次，快到 debounce 或 loading 狀態來不及擋。測出來的問題有兩種： 重複扣款 ：後端沒有冪等保護，同一個請求觸發兩次付款，使用者被扣兩次錢。 資料庫鎖死（deadlock） ：兩個幾乎同時抵達的寫入互相等對方釋放鎖，最後系統卡住、API 逾時、訂單沒寫進去但錢已經扣了。 這個手法的核心是測 連續觸發事件的防禦 。不只按鈕——下拉選單快速切換、搜尋框快速輸入、上傳檔案狂點確認，都是同一個維度。 資源中斷 核心交易進行到一半，把網路砍掉。 具體操作：在 App 的付款確認送出後兩秒內，從 Wi Fi 切到 4G，或直接開飛航模式。更暴力的版本是拔路由器線。 測的問題是： 使用者在錢已扣、但成功訊號還沒收到的空窗期失去連線，會發生什麼？ 理想行為：系統判斷連線中斷，明確告知使用者「付款結果確認中，請勿重複操作」，恢復連線後能自動查詢或補通知。最壞的情況：App 顯示失敗，使用者重新付款，後端實際上已成功——使用者付了兩次。或者反過來，後端失敗但 App 顯示成功，商品沒到、錢也沒退。 「資料卡在半空中」的情境，才是資源中斷測試真正要抓的。 我遇過一隻更離譜的：在離線模式下連續完成好幾次計時，等網路恢復再手動同步，每一筆紀錄都從 1 筆變成 4 筆。資料沒有少，是被放大複製了。這隻在某個版本修掉過，幾個版本後又在同樣的情境回來。它的觸發條件很特定：離線期間累積多筆，再一次性批次同步。只測單筆離線、單筆同步，很可能碰不到它，所以「斷線期間累積多筆」本身就該是一個測試條件。 髒資料注入 把不合理的資料餵給每一個輸入口。 幾個固定要試的組合： 年齡欄 ： 1、0、999——負數有沒有被擋？上限有沒有邊界？ 姓名欄 ：輸入 10,000 字——後端截斷了嗎？資料庫欄位會不會噴 Data too long 錯誤直接吐到前端？ 金額欄 ：0、0.000001、浮點數 0.1 + 0.2——後端做四捨五入還是截斷？最小計費單位有沒有保護？ 字串欄 ：'; DROP TABLE users; 、 alert(1) ——有沒有做 SQL parameterize 和 HTML escape？ 注入要測的是 後端 validation 有沒有在守門 。前端的限制使用者可以繞過（直接打 API 就好），所以必須在後端驗。髒資料測試告訴你，後端的門到底有沒有鎖。 併發競態 開兩個分頁，同一個帳號，A 和 B 幾乎同時對同一筆資源操作。 最典型的例子：限購商品最後一件：A 頁面點購買，B 頁面一毫秒後也點購買，看看會不會同時成功、出現超賣。 更隱蔽的版本：使用者同時開兩個分頁編輯同一份個人資料，各自修改不同欄位，先後送出，後送出的覆蓋先送出的，哪些欄位會消失？ 這個維度測的是 狀態同步與競態條件的防禦 ——後端有沒有用樂觀鎖（optimistic lock）或資料庫事務（transaction）保護共用資源，讓兩個同時抵達的操作不會都以為自己是贏家。