🔧 阿川の電商水電行
引言
如果有安全問題，後果將非常嚴重。
普通的錯誤可能只會造成不便，但安全漏洞可能會導致帳戶被盜、資訊洩漏、服務中斷等無法挽回的後果。
為了預防這類重大事故，本文將參考 OWASP Top 10:2025，幫助初學者了解「哪裡存在危險」以及「可以採取什麼措施進行防範」。
OWASP Top 10:2025 是什麼
OWASP Top 10 是將網路應用程式中容易發生且危害性大的安全事故模式整理成的10個類別。
10個類別一覽
- A01 破損的存取控制
- A02 安全設定錯誤
- A03 軟體供應鏈失敗
- A04 加密失敗
- A05 注入攻擊
- A06 不安全的設計
- A07 認證失敗
- A08 軟體或數據完整性失敗
- A09 安全日誌和警報失敗
- A10 異常條件的處理失誤
接下來，將針對各類別
1) 可能發生什麼 → 2) 常見範例 → 3) 對策 → 4) 用語備忘
的順序進行整理。
A01 破損的存取控制
1) 可能發生什麼
這是指系統未能正確判定特定使用者是否有權進行某項操作或存取某項資料的情況。
即便介面被隱藏，透過 API 或 URL 直接アクセス仍然容易被突破。
2) 常見範例
- 僅透過更改 URL 的 id 就能看到他人的資訊（IDOR）
- 一般使用者能夠存取管理者用的 API
- 能夠更新或刪除非自己的訂單或發布內容
3) 對策
- 權限檢查必須在伺服器端進行（不應信任前端控制）
- 原則上拒絕（deny by default），僅允許通過的操作
- 逐筆記錄進行擁有者檢查（檢查這個用戶是否可以操作這筆資料）
- 將權限錯誤記錄在日誌中，若重複發生則連結至警報（與 A09 互動）
4) 用語備忘
- 存取控制：決定誰可以做什麼的機制（與登錄不同）
- API：伺服器的請求接口，可以透過直接輸入 URL 進行呼叫
- 直接輸入 URL：不透過按鈕，直接在地址欄輸入連結進行存取
- IDOR：輕易地將其他人的資料 ID 更換後顯示出來的狀態
- 原則上拒絕（deny by default）：原則是全部拒絕，僅允許必要的操作通過的看法
A02 安全設定錯誤
1) 可能發生什麼
應用程式、伺服器或雲端的設定未處於安全狀態，且以不當方式公開。
生產環境中的疏忽屢見不鮮，造成的損害往往更為嚴重。
2) 常見範例
- 生產環境中開啟了調試模式，顯示堆疊追蹤
- 留下未使用的管理介面或範例
- 雲端儲存意外公開設定
- CORS 或安全頭部設定過於弱，未進行設定
3) 對策
- 將開發用和生產用的設定分開（以安全為基準預設生產環境）
- 刪除不必要的功能或服務，關閉未使用的埠
- 將設定代碼化以便進行審查（基礎設施即代碼或設定檔管理）
- 不要將秘密資訊（如 API 金鑰等）直接寫入程式碼中，權限需最小化
4) 用語備忘
- 生產環境：使用者實際使用的公開環境
- 調試模式開啟：顯示詳細錯誤訊息的設定（在生產環境中危險）
- 堆疊追蹤：錯誤原因的歷史紀錄，對攻擊者也可以提供線索
- CORS：規則，決定是否可以從不同的網站呼叫 API，若設定過於寬鬆則易被濫用
- 安全頭部：為了安全而附加在瀏覽器中的額外訊息
A03 軟體供應鏈失敗
1) 可能發生什麼
即使自己的代碼是正確的，但如果依賴的庫、開發端、CI/CD或分發途徑被攻擊，惡意代碼或被篡改的結果物將會混入其中。
2) 常見範例
- 依賴的套件被駭客入侵，更新中混入惡意程式碼
- CI 的憑證洩漏，建置結果被置換
- 發佈權限過於強大，任一人的錯誤操作或侵害將立即反映在生產環境
3) 對策
- 固定依賴關係的版本（使用鎖檔）
- 定期執行依賴關係的脆弱性掃描（理想情況下自動化）
- 最小化 CI/CD 的權限，對秘密資訊的處理需嚴格管理
- 在發佈流程中加入審查和批准，考慮階段性發佈
4) 用語備忘
- 供應鏈：包含部件（庫）和工具（CI）及分發的整個供應過程
- 依賴庫：自己的應用所使用的外部元件
- 鎖檔：固定部件版本的檔案（例如：package-lock.json）
- CI/CD：自動測試、自動建置、自動發佈的機制
- 憑證：自動化登入時使用的密碼，洩漏會導致權限被奪取
A04 加密失敗
1) 可能發生什麼
因為未進行加密、所使用的方法太弱、密鑰管理不當等原因，機密資訊可能會洩漏或被篡改。
處理密碼或個人資訊時，這是最優先需要整頓的領域。
2) 常見範例
- 不強制使用 HTTPS
- 以明文保存密碼
- 使用弱雜湊或過舊的加密方式
- 將密鑰放入源代碼或儲存庫中
3) 對策
- 通信必須以 HTTPS（TLS）為前提，不允許 HTTP
- 密碼應使用專門的雜湊方法進行存儲（例如：bcrypt/Argon2/PBKDF2），不可自行實作
- 密鑰應在安全的存放地進行管理（不僅限於環境變數，也應考慮專用的儲存）
- 加密涉及的对象、密鑰及運用（如循環更新）都需整套設計
4) 用語備忘
- HTTPS/TLS：防止通信被竊聽和篡改的機制
- 明文：未經加密可直接讀取的文字
- 雜湊：不可逆的轉換（用於保存密碼）
- 密鑰：加密的鑰匙，若洩漏則加密失去意義
- 循環更新：定期交換密鑰的運用
A05 注入攻擊
1) 可能發生什麼
用戶的輸入被解釋為命令而非數據，在數據庫、作業系統或瀏覽器側被不當執行的問題。
代表性的例子有 SQL 注入攻擊與 XSS 攻擊。
2) 常見範例
- SQL 注入攻擊可以從數據庫中獲取或修改資訊
- XSS 攻擊讓其他人的瀏覽器執行腳本，竊取 Cookie 或進行畫面操作
- 命令注入導致伺服器上執行命令
3) 對策
- SQL 查詢必須使用參數化查詢（佔位符）。切勿用字串直接拼接
- 顯示在 HTML 上的值必須適當地進行轉義（了解模板的自動轉義）
- 輸入驗證應採用許可清單式進行（阻擋非預期的輸入）
- 針對不同上下文進行轉義（HTML、屬性、URL、JS 字串等需要不同處理）
4) 用語備忘
- SQL：用於查詢數據庫的語言
- XSS：輸入混入 HTML 中，讓他人瀏覽器執行腳本
- Cookie：在瀏覽器中保存登入狀態等的機制（被竊取後會危險）
- 參數化查詢：用於安全補全 SQL 的機制
- 轉義：中和字符以便安全顯示的過程
A06 不安全的設計
1) 可能發生什麼
在實作錯誤之前，規格或設計本身就存在易受攻擊的情況。
由於後期修正成本較高，因此在最初階段就進行優化是非常有效的。
這不是具體的安全問題，而是與思維方式有關的一個話題。
2) 常見範例
- 重要操作沒有次數限制，導致暴力破解可能
- 認證或權限的規範不明，會產生漏洞
- 失敗時的行為未定義，可能出現意外的成功
3) 對策
- 針對重要流程（登入、權限、支付、設定變更）以攻擊者的角度進行思考（威脅建模）
- 規範中加入限制（次數限制、雙重確認、冷卻時間、稽核日誌）
- 設定安全的預設值（錯誤時拒絕、公開範圍最小化）
4) 用語備忘
- 設計：在實作之前制定的規則。這裡若弱點，則即便實作正確也會被突破
- 威脅建模：提前識別攻擊者可能的目標
- 安全的預設值：當不確定時，傾向安全的一方（拒絕、非公開、最小權限）
A07 認證失敗
1) 可能發生什麼
登入、會話、憑證和密碼重置的安全性不足，容易造成身份盜竊。
許多設計未能抵抗密碼洩漏的重複使用或暴力破解。
2) 常見範例
- 登入嘗試的次數沒有限制，容易遭受暴力破解
- 會話 ID 被盜、固定或無法失效
- 密碼重置過程易於猜測
3) 對策
- 可能的話導入 MFA（多因素驗證）
- 設定登入失敗次數限制、延遲以及針對 IP 或設備的防禦
- 登入後重新發行會話，並適當設置 Cookie 屬性（SameSite）
- 確保透過登出或過期將會話無效化
4) 用語備忘
- 認證：確認你是誰的過程（登入）
- MFA：二段式驗證。如果密碼洩漏也不易被突破
- 會話 ID：表示正在登入狀態的識別號（被盜取將導致身份盜竊）
- 憑證：表示登入狀態的字串（通常在 API 中使用）
- SameSite：設定使得 Cookie 更難經由其他網站傳送
A08 軟體或數據完整性失敗
1) 可能發生什麼
「雖然已被篡改，但卻相信它是正確的並進行處理」的問題。
應用程式會接收來自外部的內容（更新檔案、Webhook、設定檔、快取、備份、整合資料等），如果這些內容在途中被修改而未經驗證，則可能會執行或保存攻擊者所需的資訊。
形象化比喻：快遞包裹在未開封之前已被調包，但卻不檢查內容就直接使用。
A03（供應鏈）是「供應方（庫/CI/分發）遭受攻擊」，
而 A08 是「在未驗證的情況下信任接收到的內容」。
2) 常見範例
- 更新檔（應用程式/插件等）未經簽名確認便直接應用
- 將 Webhook 或外部 API 的資料視為「因為是整合方而安全」，隨意用於重要處理
- 將危險格式的資料反序列化，導致意外的處理（可能導致 RCE 等問題）
3) 對策
- 對於重要的檔案或資料，必須透過 簽名（簽名檔） 或 雜湊 確認其是否「未被篡改」後才使用
- 對於外部輸入（Webhook/外部 API/上傳），務必 驗證後使用（形式、範圍、預期的發送者等）
- 在更新、分發及匯入的邊界（CDN、儲存、CI、接收 API）設置 驗證點
- 最小化反序列化，若可能則限制至安全格式，如必須使用則僅允許簽名資料
4) 用語備忘
- 完整性（Integrity）：數據或程式碼未被篡改的狀態
- 簽名（數位簽名）：確認分發來源為正確且未被修改的機制
- 雜湊檢查：內容即使有一個字元變更也會導致值改變，進而檢測篡改
- 信任邊界：決定從此處以後的輸入為「不信任」的邊界（外部整合或上傳在邊界外）
- 反序列化：將字串/位元組序列轉回物件的過程，某些格式可能存在危險
A09 安全日誌和警報失敗
1) 可能發生什麼
即使遭受攻擊也無法察覺或察覺後無法行動的情況。
即便有日誌，若沒有警報則易導致延遲發現、損害擴大。
2) 常見範例
- 登入失敗的記錄未被保存
- 權限錯誤或重要操作沒有日誌
- 日誌存在但未有人查看通知
- 誤檢測過多導致真正的警報被埋沒
3) 對策
- 決定需監察的事件並進行記錄（日誌化）（認證、權限、重要操作、設定變更）
- 進行日誌保全與集中管理（避免篡改、保存期限）
- 設定異常條件並發出警報（連續失敗、權限錯誤急增等）
- 準備在接收到警報後的後續步驟（初步行動、聯繫、封鎖）
4) 用語備忘
- 日誌：記錄發生了什麼的紀錄
- 監察日誌：為了後續追蹤而保存的關鍵事件的日誌
- 警報：通知異常並使其能夠開始行動的狀態
- 集中管理：將日誌集中在一處以便保護（避免被刪除）
- 誤檢測：本來不存在問題卻發出警報；太多會導致沒有人查看
A10 異常條件的處理失誤
1) 可能發生什麼
「當事情失敗（錯誤、缺失、超時、故障）時，系統無法安全停止」的問題。
原本失敗時應當「拒絕」、「中斷」或「回退」，但如果異常處理不當，就會導致不該執行的處理被執行（fail open）、內部資訊洩漏、數據損壞、重複處理等事故。
形象化比喻：收銀機故障卻出現「0元購買」的情況。
2) 常見範例
- 當必填參數缺失時，權限檢查被跳過（原本應拒絕卻被通過＝fail open）
- 異常訊息中顯示 內部資訊（檔案路徑、SQL、設定名、秘密提示）
- 在中途失敗的情況卻被視為「成功」而數據被部分更新（無法回退）
- 超時後再試執行導致重複處理（重複扣款、庫存誤減）發生
- 當外部整合失敗時，以「暫時 OK」前進，導致後續資料不一致
3) 對策
- 在失敗的情況下基本上應當拒絕（fail closed）
- 當發生異常時，應該處理為「無權限」、「處理中斷」、「安全的錯誤」。
- 錯誤顯示應該是 對使用者簡單常規 的，詳細資訊則僅記錄在伺服器日誌中
- 畫面顯示：
處理失敗。請再試一次。 - 日誌：異常名稱、堆疊追蹤、請求 ID、使用者 ID 等
- 畫面顯示：
- 重要處理（支付、庫存、權限變更）應當設計為在中途失敗時回退
- 資料庫交易、回退處理
- 有重試行為的處理應當抵禦重複執行的破壞（冪等性）
- 設計「同一訂單 ID 僅反映一次」的機制
- 加入異常測試
- 測試必填項缺失、權限不足、超時、重複發送、外部 API 失敗
4) 用語備忘
- 異常條件：非正常狀態（缺漏、故障、超時、非預期輸入等）
- fail open：錯誤時「放行」的行為（危險）
- fail closed：錯誤時必須「拒絕」的做法（安全）
- 回退：如果中途失敗，則將更改恢復至原狀
- 冪等性：同一請求處理多次仍會得到相同結果的特性
- 內部資訊：對攻擊者有幫助的資訊（如路徑、SQL、設定名、秘密提示等）
最小檢查清單
- 每個 API 均有進行權限檢查（包括擁有者確認）
- 登入有簡化次數限制及會話重新發行
- 生產環境中已關閉調試、關閉不必要功能、秘密資訊有安全管理
- SQL 使用參數化，輸出進行轉義
- 認證失敗、權限錯誤及重要操作被記錄在日誌中，異常須能夠通知
- 錯誤時進行拒絕，確保安全方案，例外詳細不應外洩
原文出處：https://qiita.com/shibata1111/items/e64b9f26c54607f7862b
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
