34. 承上題，下列何者較可解決此一問題？
(A) 登入後還必須加上雙因子驗證才能防範
(B) API 應該加上次數限制
(C) 在網頁前端進行授權檢查即可解決
(D) 將相關參數雜湊加鹽隱碼處理

答案：登入後查看
統計： A(3), B(0), C(2), D(6), E(0) #3871609

詳解 (共 1 筆)

#7367494

這題的正確答案是 (D) 將相關參數雜湊加鹽隱碼處理（或廣義上的「使參數不可預測與不可見」）。

然而，這題在實務開發與資安標準中，最強調的解決核心其實是後端權限檢驗。但在題目給定的選項範圍內，(D) 是最能直接針對「修改數值（暴力猜測）」行為產生阻礙的技術手段。以下是詳細分析：

選項分析與說明

選項 做法評價 原因說明
(A) 無效 雙因子驗證 (2FA) 解決的是「身份識別 (Authentication)」問題（確認你是誰），而本題弱點在於「授權 (Authorization)」（確認你有權看這筆資料）。即便開了 2FA，登入後若後端沒鎖權限，依然可以改 orderId 看別人的資料。
(B) 治標不治本 API 次數限制 (Rate Limiting) 可以減緩攻擊者「大規模」爬取資料的速度，但無法阻止攻擊者手動或緩慢地修改數值來精準竊取特定訂單資料。它屬於防禦深度 (Defense in Depth)，而非根治方案。
(C) 絕對不可行 資安大忌。 前端程式碼（JavaScript）是可以被使用者自由修改與繞過的。任何關於安全與權限的檢查，必須在後端 (Server-side) 進行，前端檢查僅是為了提升使用者體驗，不能作為安全防線。
(D) 較佳方案 正確答案。 這屬於「間接對象引用 (Indirect Object Reference)」的應用。若將原本具規律性的 orderId=1001 改為雜湊 (Hash) 處理或加密後的字串（如 orderId=a8f9c2...），攻擊者便無法透過簡單地加減數值來猜測其他人的訂單號碼，從而阻斷 IDOR 攻擊路徑。

實務上的最佳解法 (Best Practice)

雖然選項 (D) 透過隱碼處理提高了攻擊難度，但在專業的資安開發 (Secure Coding) 中，最根本的解法應為：

  1. 後端強制檢查屬主關係：

    在執行資料庫查詢時，必須同時檢查 OrderId 與 UserId。

    SQL

    -- 錯誤做法：只查編號 SELECT * FROM Orders WHERE OrderID = '12345';

    -- 正確做法：同時驗證目前登入者身分 SELECT * FROM Orders WHERE OrderID = '12345' AND CustomerID = 'Current_User_Session_ID';

  2. 使用 UUID (通用唯一識別碼)：

    取代流水號 (Auto-increment ID)，使用如 550e8400-e29b-41d4-a716-446655440000 這種隨機且極長且不可預測的碼，效果與選項 (D) 類似且更符合現代架構。

  3. 隱碼處理與加鹽 (Salt)：

    如選項 (D) 所述，如果必須使用流水號，在傳遞給前端前先進行雜湊加鹽，使外部看到的參數完全無規律可循。

在您的 IT 環境中，若有涉及 NHI VPN 或敏感醫療數據的傳輸，這類 API 的權限校驗通常是 ISO 27001 稽核與滲透測試 (Penetration Test) 中的重中之重。

0
0