# OWASP Top 10: 2025 (Web Applications) iPAS 考前重點精華版

> **資料來源**：OWASP Top 10:2025 （2025/12/31公布）
> **適用對象**：iPAS 資安工程師考前複習
> **整理者**：林志祥
> **修改時間**：2025/12/31

---

## 🔥 考前超熱門：2021 vs 2025 排名變動全解析

**2021 到 2025 的排名升降是 iPAS 選擇題的熱門考點，請務必記住以下關鍵變動（如 SSRF 的去向或 A03和A10的新增）：**

<center>圖1：2025年OWASP Top10從2021年到2025年的變化。資料來源：<a href="https://owasp.org/Top10/2025/">OWASP Top10</a></center>

### 📝 變動重點筆記
1. **A10 SSRF (伺服器端請求偽造) 去哪了？**
* **考試必考**：SSRF 在 2025 版已被移除獨立排名，主要被 **併入 A01 (存取控制失效)**。因為 SSRF 本質上就是利用 Server 的權限去存取不該存取的內部資源（越權）。
2. **誰是新面孔 / 改頭換面？**
* **A03 軟體供應鏈失效 (前身 A06)**：
* **變動**：從單純檢查「元件過期 (Vulnerable Components)」擴大為「供應鏈安全」。
* **重點**：不再只看 CVE，更看重 **CI/CD 流程安全**、**惡意程式植入** 與 **SBOM** 管理。
* **A10 異常狀態處理不當 (全新類別)**：
* **變動**：這是一個**全新的分類標題**，填補了舊版 A10 (SSRF) 移走後的空缺。
* **重點**：聚焦在程式出錯時的行為，如 **Fail Open (失效開放)** 安全機制崩潰，或 **Stack Trace 洩漏** 敏感資訊。
3. **誰升官了？ (威脅變大)**
* **A02 安全配置錯誤** (原 A05)：因為雲端 (Cloud) 與微服務架構太複雜，人為設定錯誤的風險大幅提升。
4. **誰降級了？ (但還是很重要)**
* **A05 注入攻擊** (原 A03)：受惠於現代框架 (ORM) 預設防護，發生率下降，但破壞力依然很高。

---

## 📊 考前必背 1：Top 10 是怎麼產生的？(8+2 原則)

OWASP Top 10 結合了「數據」與「經驗」：
1. **數據驅動 (Data Driven) ⮕ 8 項**：
依照資安廠商提供的漏洞「發生率」選出。代表 **「現在最常發生的問題」**。
2. **社群調查 (Community Survey) ⮕ 2 項**：
由資安專家投票選出 **「工具掃不到」** 或 **「未來潛在高風險」** 的項目。
* **在本清單中是哪兩項？** (考試口訣：**3 跟 9 是選出來的**)
1. **A03 軟體供應鏈失效 (第 3 名)**：上游廠商被駭或開源風險，很難單靠掃描器量化，專家認為是未來最大威脅。
2. **A09 安全日誌與告警失效 (第 9 名)**：日誌紀錄是否足夠、告警是否有效，極度依賴人工判斷，工具難以檢測。

## 🧪 考前必背 2：標準與成熟度模型 (Top 10 vs ASVS vs SAMM)

:::danger
**🚫 觀念導正：Top 10 不是驗收標準！**
**OWASP Top 10 是「十大死因（意識文件）」，不是「健康檢查表」。**
若合約寫「本系統符合 OWASP Top 10」，代表只檢查了這 10 項，其他 100 項漏洞都沒測，系統依然不安全。
:::

### 📝 考試必考：OWASP 三大支柱比較
這三個常常混在一起考，請務必分清楚用途：

| 專案名稱 | 全名 (中文) | 用途與定位 | 譬喻 |
| :--- | :--- | :--- | :--- |
| **Top 10** | Top 10 Risks | **【意識 Awareness】**<br>列出最嚴重的 10 個風險，提醒大眾注意。 | **「十大死因」**<br>(知道要注意心臟病和癌症) |
| **ASVS** | Application Security Verification Standard<br>(應用程式安全驗證標準) | **【檢測標準 Standard】**<br>用來驗收 **「產品」**。滲透測試或驗收時的 Checklist。 | **「健康檢查表」**<br>(檢查血壓、血糖是否達標) |
| **SAMM** | Software Assurance Maturity Model<br>(軟體保證成熟度模型) | **【流程成熟度 Maturity】**<br>用來評估 **「公司/團隊」** 的開發制度是否健全。 | **「醫院評鑑」**<br>(這家醫院的SOP好不好？) |

### 🛠️ 1. 如果要驗收產品 ⮕ 用 ASVS
依據系統重要性，選擇驗證等級：
* **Level 1 (Basic)**：基本掃描 (自動化工具可達)，適用於低風險系統。
* **Level 2 (Standard)**：**業界標準**。包含大多數的控制項，適用於處理個資的系統 (B2B/B2C)。
* **Level 3 (Advanced)**：高強度驗證。適用於國防、金融、醫療等高敏感系統。

### 📈 2. 如果要改善開發流程 ⮕ 用 SAMM

評估企業在軟體開發生命週期 (SDLC) 中的成熟度，分為五大構面：
1. **治理 (Governance)**：有沒有制定策略與指標？
2. **設計 (Design)**：有沒有做威脅建模？
3. **實作 (Implementation)**：有沒有安全編碼規範？
4. **驗證 (Verification)**：有沒有做 Code Review 和測試？
5. **維運 (Operations)**：有沒有漏洞管理與事件應變？

---

## A01 存取控制失效（Broken Access Control）

:::info
**💡 定義**
系統未能正確實施權限管制，導致使用者可以執行超出其權限的操作。
**2025 重點變動**：**SSRF (伺服器端請求偽造)** 在本版不再獨立排名，其核心概念「伺服器被濫用權限去存取內部資源」常被視為廣義的存取控制問題。
:::

### 🚨 常見失效型態 (必考概念)
1. **垂直越權 (Vertical Escalation)**：
* **概念**：地位低 ⮕ 地位高。
* **情境**：一般會員 (User) 成功存取或操作管理員 (Admin) 的後台功能。
2. **水平越權 (Horizontal Escalation / IDOR)**：
* **概念**：此人 ⮕ 他人 (同級別)。
* **情境**：會員 A 修改網址參數 (`id=100` 改 `id=101`)，偷看會員 B 的訂單資料。
3. **情境/流程越權 (Context-Dependent Escalation)**：
* **概念**：**時間點**或**狀態**錯誤。
* **情境**：離職員工帳號忘記刪除或使用者跳過「付款頁面」直接存取「下載頁面」；或是在訂單「已出貨」狀態下，仍能呼叫 API 修改收件地址。這是屬於**業務邏輯 (Business Logic)** 的漏洞。
4. **路徑遍歷 (Path Traversal)**：
* **情境**：利用 `../` 跳脫網頁目錄，存取系統敏感檔案 (如 `/etc/passwd`)。

### 🚨 實戰案例
**麥當勞徵才機器人 IDOR**
研究人員發現只要修改網址 URL 參數 (如 `applicant_id`)，後端未檢查該 ID 是否屬於當前登入者，導致可越權存取其他應徵者的個資。
> [新聞來源：iThome](https://www.ithome.com.tw/news/170050)

### 🛡️ 核心防禦：伺服器端驗證 + 間接參考
1. **伺服器端驗證 (Server-Side Check)**：
* 絕對**不可信任前端** (隱藏按鈕不代表安全)。
* 每次 API 呼叫都需在後端檢查 `if (current_user == resource_owner)`。
2. **使用間接參考 (Indirect Reference)**：
* **防禦 IDOR 的神技**。不要在 URL 使用連續的資料庫 ID。
* ❌ **危險**：`mysite.com/data?id=1001` (易被猜測/遍歷)
* ✅ **安全**：`mysite.com/data?id=xc9-1a2` (使用隨機雜湊 Map 對應)
3. **狀態檢查 (Stateful Validation)**：
* 針對情境越權，後端必須檢查當前狀態。例如：`if (order.status != 'SHIPPED')` 才能修改地址。

:::warning
**📝 iPAS 考試重點：關鍵字抓題**
1. **IDOR (物件參考不安全)**：題目出現 **「修改 URL 參數 (ID)」**、**「遍歷流水號」**。
2. **Path Traversal (路徑遍歷)**：題目出現 **`../../`**、**`..\`**、**`%2e%2e%2f`** 或 **存取系統檔**。
3. **情境越權 (Business Logic Bypass)**：題目描述 **「跳過步驟」**、**「未付款先取貨」**。
:::

---

## A02 安全配置錯誤（Security Misconfiguration）

:::info
**💡 定義**
安全控制機制存在，但未被正確啟用或設定。這通常發生在應用程式堆疊的任何層級（雲端、網路、資料庫、框架）。
**2025 趨勢**：排名由 A05 飆升至 **A02**，主因是雲端環境（AWS/Azure）複雜度導致人為設定失誤（如 S3 Bucket 外洩）激增。
:::

### 🚨 常見四大失效型態
1. **預設值未改 (Default Accounts)**：
* 使用原廠預設帳密 (admin/admin) 或範例程式碼。
2. **雲端儲存權限大開 (Cloud Misconfig)**：
* S3 Bucket 或 Azure Blob 設定為 `Public Read`，導致機敏資料裸奔。
3. **錯誤訊息洩漏 (Information Leakage)**：
* 未關閉 **Debug Mode**，導致錯誤發生時顯示 Stack Trace（程式路徑、資料庫語法）。
4. **XXE (XML 外部實體攻擊)**：
* XML 解析器配置錯誤，允許載入外部實體，導致駭客可讀取 `/etc/passwd`。**(註：XXE 在 Top 10 中主要歸類於此)**

### 🚨 實戰案例
1. **Capital One 資料外洩案 (雲端配置)**：
* 因 AWS WAF (防火牆) 配置錯誤，權限過大，讓駭客得以利用 SSRF 手法存取後端 S3 資料庫。
> [新聞來源：iThome](https://www.ithome.com.tw/news/139316)
2. **iRent 資料庫外洩 (未設密碼)**：
* 資料庫主機直接暴露在公網，且完全未設定密碼保護，任何知道 IP 的人都能連線。
> [新聞來源：iThome](https://www.ithome.com.tw/news/155392)

### 🛡️ 核心防禦：安全硬化 (Hardening)
1. **移除預設值**：
* 上線前務必更改預設帳密，移除範例應用程式 (Sample App)。
* 關閉不必要的通訊埠 (Ports) 與服務。
2. **自動化配置審查**：
* 使用工具 (如 AWS Config, ScoutSuite) 定期掃描雲端環境是否符合安全基線(Security Baseline)。
3. **統一錯誤處理**：
* 設定統一的錯誤頁面 (如 404/500 自訂頁面)，禁止顯示除錯資訊。
4. **安全標頭 (Security Headers)**：
* 設定 `HSTS` (強制 HTTPS)、`X-Frame-Options` (防 Clickjacking)、`CSP` (防 XSS)。

:::warning
**📝 iPAS 考試重點：關鍵字抓題**
1. **看到「預設」就選它**：題目出現 **「預設帳密」**、**「預設安裝」**。
2. **看到「洩漏環境資訊」就選它**：題目描述 **「Banner Grabbing」** (看到 Server 版本號)、**「Directory Listing」** (看到檔案目錄)。
3. **看到 XXE**：若題目問 XXE 屬於哪一類，選 A02 (配置錯誤) 或 A05 (注入)，但在新版邏輯偏向配置錯誤 (解析器設定問題)。
4. **關鍵字：安全硬化(Hardening)、安全基線(Security Baseline)**：這是解決配置錯誤的標準術語。
:::

---

## A03 軟體供應鏈失效（Software Supply Chain Failures）

:::info
**💡 定義**
應用程式依賴的第三方元件（Libraries, Frameworks）、上游供應商或 CI/CD 建置與交付流程缺乏安全管控，導致引入了已知漏洞或惡意後門。
**前身**：A06 Vulnerable and Outdated Components (範圍擴大)。
:::

### 🚨 供應鏈攻擊的三種層次
1. **使用到已知漏洞元件 (Old but Gold)**：
* 使用了過期且含有 CVE 的 jQuery、Struts2 或 Log4j 版本。
2. **惡意程式碼植入 (Malicious Injection)**：
* 駭客入侵開源專案維護者帳號，或在 NPM/PyPI 上傳相似名稱的惡意套件 (**Typosquatting**，如 `requesrs` 混淆 `requests`)。
3. **建置流程汙染 (Pipeline Compromise)**：
* 駭客入侵 CI/CD 伺服器 (如 Jenkins, TeamCity)，在軟體打包過程中偷偷塞入後門 (如 SolarWinds 案)。

### 🚨 實戰案例
1. **Log4Shell (Log4j) 事件**：
* **關鍵字**：**Java 日誌元件**、**零時差漏洞**、**影響範圍極廣**。
* **教訓**：企業根本不知道自己哪裡用了 Log4j，突顯了 SBOM 的重要性。
> [新聞來源：iThome](https://www.ithome.com.tw/news/162130)
2. **SolarWinds 供應鏈攻擊**：
* **關鍵字**：**官方更新檔被植入後門**、**Orion Platform**。
* **教訓**：駭客攻擊上游軟體商，即便是「合法的數位簽章更新」也可能帶毒。
> [新聞來源：iThome](https://www.ithome.com.tw/news/149530)
3. **XZ Utils 後門 (2024)**：
* **關鍵字**：**社會工程**、**Linux 壓縮工具**、**惡意維護者**。
* **教訓**：開源專案的「人」也是供應鏈脆弱的一環。
> [新聞來源：iThome](https://www.ithome.com.tw/article/141943)
4. **Cache Panda 金融供應鏈攻擊**：
駭客利用軟體供應商的維運 VPN 通道作為跳板，滲透進台灣金融機構內網。
> [新聞來源：iThome](https://www.ithome.com.tw/news/149530)

### 🛡️ 核心防禦：SBOM + SCA
1. **建立 SBOM (軟體物料清單)**：
* 使用標準格式 (如 **CycloneDX** 或 **SPDX**) 記錄所有引用的元件清單。
2. **導入 SCA (軟體成分分析) 工具**：
* 在 CI/CD 流程中自動掃描 SBOM，比對 CVE 資料庫，發現風險立即阻擋 Build。
3. **私有儲存庫 (Private Repository)**：
* 在企業內部建立 Nexus/Artifactory，快取外部套件並進行掃描，避免開發者直接從公網下載惡意套件。
4. **簽署與驗證 (Signing & Verification)**：
* 導入如 Sigstore/Cosign 等工具，對容器映像檔 (Docker Image) 和程式碼進行數位簽章與驗證。

:::warning
**📝 iPAS 考試重點：工具與關鍵字**
1. **必考題：SCA vs SAST**
* 問「檢查**自行開發**的原始碼」 ⮕ 選 **SAST**。
* 問「檢查**第三方套件/引用函式庫**」 ⮕ 選 **SCA**。
2. **必考題：SBOM**
* 題目問「如何快速盤點受漏洞影響的資產？」或「主要防禦供應鏈攻擊的文件？」 ⮕ 選 **SBOM**。
3. **名詞解釋**：
* **Typosquatting** (誤植網域/套件名攻擊)：故意取很像的名字 (如 `Gooogle.com` 或 `npm install reqest`) 騙你下載。
:::

---

## A04 加密機制失效（Cryptographic Failures）

:::info
**💡 定義**
未能正確保護敏感資料（如密碼、個資、信用卡號）。包含使用過時的加密演算法、預設密碼金鑰、或未強制使用加密傳輸（HTTPS）。
:::

### 🚨 常見失效型態
1. **使用過時/脆弱演算法**：
* 使用 **MD5** 或 **SHA-1** 儲存密碼 (容易被碰撞或彩虹表破解)。
* 使用 **DES** 或 **RC4** 進行加密。
* 使用 **ECB 模式** (Electronic Codebook) 進行加密 (因相同的明文會產生相同的密文，無法隱藏資料樣式)。
2. **明文傳輸**：
* 網站使用 **HTTP、FTP、Telnet** 等未加密協定傳輸敏感資料，或是考需要使用 **HTTPS、SFTP、SSH** 。
3. **金鑰管理不當**：
* 將加密金鑰 (Cryptographic Keys) **寫死 (Hardcoded)** 在程式碼中並上傳到 GitHub。
4. **密碼學隨機性不足**：
* 使用 `Math.random()` 等偽隨機函數產生金鑰，導致可被預測。應使用加密安全的隨機產生器 (CSPRNG)。
5. **憑證驗證失敗**：
* 未驗證伺服器憑證的有效性，或忽略憑證錯誤（接受自簽憑證）。

### 🚨 實戰案例
1. **Adobe 密碼外洩案 (加密模式錯誤)**：
* Adobe 曾使用 **3DES + ECB 模式** 加密用戶密碼。因 ECB 模式特性，導致駭客發現大量用戶使用相同的密碼 (產生相同的密文)，輕鬆破解數百萬帳戶。
> [新聞來源：資安人](https://www.informationsecurity.com.tw/article/article_detail.aspx?aid=7699)
2. **網站未強制 HTTPS**：
* 使用者在咖啡廳使用公共 Wi-Fi 登入 HTTP 網站，Cookie 與帳密遭駭客透過中間人攻擊 (MITM) 竊聽。
> [新聞來源：iThome](https://www.ithome.com.tw/news/137532)
3. **饗賓餐飲個資外洩**：
* 會員密碼僅使用 **MD5** 弱雜湊演算法儲存，導致資料外洩後極易被暴力破解還原。
> [新聞來源：iThome](https://www.ithome.com.tw/news/137532)

### 🛡️ 核心防禦：強加密 + 妥善金鑰管理
1. **資料傳輸 (Data in Transit)**：
* 強制全站使用 **TLS 1.2 或 1.3** (HTTPS)。
* 啟用 **HSTS (HTTP Strict Transport Security)** 強制瀏覽器只用 HTTPS 連線。
2. **密碼儲存 (Password Storage)**：
* **絕對禁止**：明文、Base64、MD5、SHA-1。
* **推薦作法**：使用專用演算法 **Argon2id**、**bcrypt** 或 **PBKDF2**，並針對每個用戶加入隨機 **Salt (鹽值)** 以防禦彩虹表 (Rainbow Table)。
3. **資料儲存 (Data at Rest)**：
* 使用 **AES-256 (GCM 模式)** 或 **ChaCha20**。
4. **金鑰管理**：
* 使用專用的金鑰管理系統 (KMS) 或硬體安全模組 (HSM)，嚴禁將金鑰存放在程式碼或設定檔中。

:::warning
**📝 iPAS 考試重點：陷阱題大集合**
1. **Base64 不是加密！**
* 題目若說「將資料轉為 Base64 以保護機密性」，這是**錯**的。Base64 只是編碼，屬於 A04 的失敗案例。
2. **演算法連連看 (看到左邊就選右邊)**：
* 儲存密碼 ⮕ **Argon2, bcrypt** (+Salt)。
* 對稱式加密 (快、大量資料) ⮕ **AES**。
* 非對稱式加密 (金鑰交換、數位簽章) ⮕ **RSA, ECC**。
3. **隨機數陷阱**：
* 程式碼題若出現 `Random()` 或 `Math.random()` 產生 Token，這是弱點！必須改用 **SecureRandom** (Java) 或 **secrets** (Python)。
:::

---

## A05 注入攻擊（Injection）

:::info
**💡 定義**
未驗證的輸入資料被解釋器視為指令執行。
**包含三大類**：
1. **資料庫注入**：**SQL Injection**。
2. **作業系統注入**：**OS Command Injection**。
3. **客戶端注入**：即 **XSS (跨站腳本攻擊)**，現已併入此類別。
:::

### 🚨 實戰案例
1. **MOVEit Transfer SQL Injection (資料庫)**：
駭客利用 SQL 注入漏洞竊取資料庫內的敏感檔案。
> [新聞來源：iThome](https://www.ithome.com.tw/news/162067)
2. **路由器/Web管理介面 RCE (作業系統)**：
許多網通設備的 Web 介面提供 `Ping` 或 `Traceroute` 功能，若未過濾輸入，駭客輸入 `127.0.0.1; rm -rf /` 即可執行系統指令並接管主機。
> **情境**：常見於 IoT 設備或老舊的 Web 管理工具。
3. **eBay XSS 漏洞 (客戶端)**：
駭客在商品頁面注入惡意 JavaScript，使用者瀏覽時自動被導向釣魚網站竊取帳號。
> [新聞來源：iThome](https://www.ithome.com.tw/news/91054)

### 🛡️ 核心防禦：對症下藥
* **針對 SQL Injection (資料庫)**：
* **首選**：**參數化查詢 (Prepared Statements)**。
* *注意*：HTML 編碼對此無效。
* **針對 OS Command Injection (作業系統)**：
* **首選**：**避免直接呼叫 OS 指令** (改用語言內建 API，如 Java `File` class 代替 `rm`)。
* **輔助**：若必須呼叫，嚴格實施 **Input Validation (白名單)**，只允許數字或特定格式。
* **針對 XSS (瀏覽器/腳本)**：
* **首選**：**輸出編碼 (Output/HTML Encoding)**。將 `<script>` 轉碼為 `&lt;script&gt;`。
* **輔助**：設定 **CSP (內容安全策略)**。

:::warning
**📝 iPAS 考試重點：解法連連看**
考試最愛考「對應解法」，請務必分清楚：
* 題目問 **SQL Injection** ⮕ 找 **Prepared Statements** (參數化)。
* 題目問 **OS Command Injection** ⮕ 找 **Input Validation (白名單)**，題目常愛寫成黑名單 或 **避免 System Call**。
* 題目問 **XSS** ⮕ 找 **Output Encoding** (輸出編碼) 或 **CSP**。

**⚠️ 陷阱**：題目問 SQL 防禦，選項出現「HTML 編碼」➡ **千萬別選！** 那是治 XSS 的藥。
:::

---

## A06 不安全設計（Insecure Design）

:::info
**💡 定義**
這不是程式碼實作錯誤 (Implementation Bug)，而是 **「設計階段」** 就存在的缺陷。程式碼運作完全符合設計，但設計本身缺乏安全控制（如：抗自動化不足、業務邏輯漏洞）。
**關鍵字**：資安左移 (Shift Left)、威脅建模。
:::

### 🚨 實戰案例
1. **Max 搶票機器人 (台灣 - 抗自動化不足)**：
售票系統缺乏有效的抗自動化設計（驗證碼太弱、未限制高頻請求），導致黃牛利用程式快速掃票，正常使用者無法購買。
> [新聞來源：iThome](https://www.ithome.com.tw/news/162546)
2. **無限領取優惠券 (業務邏輯漏洞)**：
電商平台設計優惠券領取流程時，未檢查「單一帳號是否已領取」，導致使用者可以重複點擊 API 無限領取折扣碼。這不是 SQL Injection，而是邏輯沒想清楚。

### 🛡️ 核心防禦：資安左移 + 威脅建模
1. **威脅建模 (Threat Modeling)**：
* **實作重點**：在寫 Code 之前的設計階段，模擬攻擊者視角（Abuse Cases）。
* **常用方法**：**STRIDE** 模型 (微軟提出)，分析欺騙 (Spoofing)、竄改 (Tampering) 等六大威脅。
2. **落實資安左移 (Shift Left)**：
* 將資安檢測從「測試階段」提前到「需求與設計階段」。
3. **限制速率 (Rate Limiting)**：
* 針對搶票、登入等高敏感功能，設計速率限制，防止自動化腳本濫用。

:::warning
**📝 iPAS 考試重點**
1. **觀念題**：如果題目描述 **「程式沒寫錯，但邏輯被玩壞」** (如：沒有檢查庫存就讓人下單、沒有限制重試次數)，這就是 **A06**。
2. **方法論**：看到 **「在開發早期發現漏洞」** 或 **「STRIDE」**，請選 **威脅建模 (Threat Modeling)**。
:::

---

## A07 身分驗證失效（Authentication Failures）

:::info
**💡 定義**
確認「你是誰」的機制失效。包含允許弱密碼、未導入多因子驗證 (MFA)、Session 管理不當（如 Session ID 暴露），導致駭客能偽裝成合法使用者。
**關鍵標準**：現代身分驗證應參考 **NIST 800-63b** 指南。
:::

### 🚨 常見失效型態 (必考名詞)
1. **撞庫攻擊 (Credential Stuffing)**：
* 駭客拿 A 網站洩漏的帳密，去嘗試登入 B 網站（因為使用者習慣共用密碼）。
2. **暴力破解 (Brute Force)**：
* 使用字典檔或窮舉法猜測密碼。
3. **Session 固定 (Session Fixation)**：
* 駭客預先取得一個有效的 Session ID，誘導受害者使用該 ID 登入，登入成功後駭客即可接管帳號。
4. **Session ID 暴露**：
* **URL Rewriting**：將 Session ID 放在網址列 (如 `http://site.com?jsessionid=xyz`)，極易在分享連結或瀏覽器紀錄中外洩。

### 🚨 實戰案例
**證券商撞庫攻擊**
駭客利用暗網流出的其他網站帳密，大規模嘗試登入台灣多家證券商下單系統。因系統僅依賴單一密碼驗證，導致大量客戶帳戶遭盜用下單港股。
> [新聞來源：iThome](https://www.ithome.com.tw/news/148411)

### 🛡️ 核心防禦：MFA + 安全 Session 管理
1. **強制實施多因子驗證 (MFA)**：
* **唯一解法**：這是對抗「撞庫」與「釣魚」最有效的手段。
2. **強化 Session 管理**：
* **登入後更換 ID**：使用者登入成功後，伺服器必須強制銷毀舊 Session ID 並配發新的，以防禦 **Session Fixation**。
* **Cookie 屬性設定**：務必設定 `HttpOnly` (防 XSS 竊取) 與 `Secure` (僅限 HTTPS 傳輸)。
3. **現代密碼政策 (NIST 800-63b)**：
* **長度 > 複雜度**：密碼長度比大小寫符號更重要。
* **取消定期更換**：除非發生外洩，否則**不建議**強制使用者每 90 天換密碼 (因為會導致使用者改用弱密碼)，**但這個是NIST 800-63b得觀點，考試得時候還是要選定期變更**。

:::warning
**📝 iPAS 考試重點**
1. **情境題關鍵字**：
* 看到 **「使用者習慣共用密碼」** 造成入侵 ⮕ 答案選 **Credential Stuffing (撞庫)**。
* 看到 **「登入後 Session ID 沒變」** ⮕ 這是 **Session Fixation** 漏洞。
* 看到 **「URL 網址列出現 jsessionid」** ⮕ 這是 **Session 暴露風險** (應改用 Cookie)。
2. **MFA 是萬用解**：大部分 A07 的問題，標準答案都是「導入 MFA」。
:::

---

## A08 軟體與資料完整性失效（Software and Data Integrity Failures）

:::info
**💡 定義**
做出關於軟體更新、關鍵資料或 CI/CD 流程的假設，但未驗證其完整性。
**兩大核心**：
1. **不安全的反序列化 (Insecure Deserialization)**：未驗證物件串流內容就將其還原為程式物件。
2. **缺乏完整性檢查**：下載更新檔或套件時，未檢查數位簽章或雜湊值。
:::

### 🚨 實戰案例
1. **React2Shell (CVE-2025-55182)**：
2025 年 12 月爆發的核彈級漏洞。知名框架 **Next.js / React** 在處理伺服器元件 (RSC) 時，因存在**不安全的反序列化**漏洞，駭客只需傳送惡意構造的 JSON 字串，後端還原物件時就會觸發惡意指令 (RCE)。
> [新聞來源：iThome](https://www.ithome.com.tw/news/172790)

2. **ASUS Live Update 供應鏈攻擊**：
駭客攻陷 ASUS 更新伺服器，並竊取合法的私鑰為惡意程式進行**數位簽章**。用戶電腦因為信任該簽章，自動下載並執行了後門程式。
> [新聞來源：iThome](https://www.ithome.com.tw/news/129588)

### 🛡️ 核心防禦：驗證、簽章、白名單
1. **針對反序列化 (Deserialization)**：
* **不信任任何輸入**：不要對來自不受信來源的資料進行反序列化。
* **型別白名單 (Type Whitelisting)**：若必須使用，嚴格限制哪些 Class 可以被反序列化。
2. **針對軟體更新/傳輸**：
* **數位簽章 (Digital Signature)**：確保程式碼由受信任的發布者簽署 (Code Signing)。
* **檢查雜湊值 (Checksum)**：下載檔案後，比對官方提供的 SHA-256 雜湊值是否一致。
3. **CI/CD 完整性**：
* 確保建置流程 (Pipeline) 也是經過簽署與驗證的，防止在編譯過程中被竄改。

:::warning
**📝 iPAS 考試重點**
1. **反序列化 (Deserialization)**：
* 關鍵字：**Java ObjectStream**, **PHP Serialization**, **Pickle (Python)**, **JSON/XML 還原物件**。
* 只要看到題目說 **「將字串還原成物件時執行了惡意程式」**，絕對選 A08。
2. **完整性檢查**：
* 題目出現 **「Checksum 不符」**、**「未驗證數位簽章」**、**「CI/CD 流程被竄改」**，也是選 A08。
:::

* **反序列化的比喻 (樂高/IKEA)**：
序列化：把組好的樂高飛機拆散，裝進盒子裡寄給你。
反序列化：你收到盒子，照著說明書把積木組回去。
漏洞：壞人在盒子裡偷偷多放了一塊「紅色按鈕積木」，並把說明書改成「組裝完畢後請按下紅色按鈕」。你照做（反序列化），結果飛機就爆炸了（執行惡意程式碼）。

---

## A09 安全日誌與告警失效（Security Logging and Alerting Failures）

:::info
**💡 定義**
未能正確記錄關鍵資安事件（如登入失敗、存取控制失效），或日誌儲存不當（被竄改/刪除），以及缺乏有效的即時告警機制。
**後果**：根據統計，企業平均需要 **200 天以上** 才能發現資料外洩，這段「駭客潛伏期」就是 A09 失效造成的。
:::

### 🚨 實戰案例
1. **健保署個資外洩案**：
內部人員利用職務之便，長期且異常地大量查詢民眾個資。因系統缺乏**行為分析 (UEBA)** 與即時告警，導致該行為持續多年未被發現。
> [新聞來源：CNA 中央社](https://www.cna.com.tw/news/asoc/202301100014.aspx)
2. **Target 百貨資料外洩**：
駭客入侵初期，資安設備其實有偵測到並發出告警。但因每日告警數量過多，管理員產生**告警疲勞 (Alert Fatigue)** 而忽略通知，錯失攔截黃金時間，導致 4000 萬信用卡資料外洩。
> [新聞來源：iThome](https://www.ithome.com.tw/news/86196)

### 🛡️ 核心防禦：SIEM + 異地備份
1. **集中化日誌管理 (Centralized Logging)**：
* **關鍵**：日誌絕對**不能只存在本機**！駭客入侵第一件事就是 `rm -rf /var/log`。
* **作法**：必須即時將日誌拋送到獨立的日誌伺服器或 **SIEM (資安事件管理平台)**。
2. **記錄關鍵事件**：
* 必須記錄：登入失敗、權限變更、伺服器端輸入驗證失敗、高權限操作。
* **不可記錄**：明文密碼、完整的信用卡號 (需遮罩)。
3. **解決告警疲勞**：
* 調整 SIEM 規則，過濾雜訊，只針對「高風險行為」發送通知。

:::warning
**📝 iPAS 考試重點**
1. **鑑識與證據**：
* 題目若問 **「如何確保駭客無法滅證？」** ⮕ 答案是 **日誌異地備份 (Remote Logging)**。
* 題目若問 **「日誌的主要資安屬性？」** ⮕ 答案是 **不可否認性 (Non-repudiation)** (證明這件事是你做的)。
2. **情境題**：
* 看到 **「潛伏半年沒人發現」** ⮕ 選 **A09**。
* 看到 **「管理員收到太多信懶得看」** ⮕ 選 **告警疲勞**。
:::

:::danger
**⚠️ 考試陷阱：日誌裡的祕密**
請注意！雖然我們在 A09 討論日誌規範，但如果題目問：
**「某工程師在 Log 檔中記錄了使用者的明文密碼，這屬於哪一類風險？」**
❌ **錯誤**：A09 (這不是日誌沒開，而是記了不該記的)。
✅ **正確**：**A04 加密機制失效** (因為密碼沒有加密/雜湊就儲存)。
:::

---

## A10 異常狀態處理不當（Mishandling of Exceptional Conditions）

:::info
**💡 定義**
當系統遭遇錯誤或異常（Exception）時，未妥善處理，導致兩個後果：
1. **洩露敏感資訊**：吐出 Stack Trace、記憶體傾印 (Memory Dump) 或資料庫結構。
2. **安全機制失效 (Fail Open)**：錯誤發生時，系統預設變為「允許存取」或「略過檢查」。
:::

### 🚨 常見失效型態
1. **詳細錯誤訊息 (Verbose Error Messages)**：
* 網頁直接噴出 `java.lang.NullPointerException` 或 SQL 語法錯誤，讓駭客得知後端使用什麼框架、資料庫版本。
2. **失效開放 (Fail Open)**：
* **情境**：防火牆軟體崩潰時，預設變成「允許所有封包通過」。
* **情境**：身分驗證伺服器斷線時，系統判定「驗證通過」讓使用者登入。
* **情境**：攻擊者故意傳送超大封包導致 WAF 記憶體不足崩潰，如果 WAF 是 Fail Open 設計，攻擊者後續的惡意流量就不會被檢測。
3. **邏輯繞過 (Logic Bypass via Errors)**：
* 在轉帳流程中，程式碼先執行「扣款」，再執行「入帳」。如果「扣款」步驟發生錯誤（如資料庫鎖死）但程式沒有正確 Catch 並終止流程，導致程式繼續往下執行「入帳」，造成無中生有的金額。

### 🚨 實戰案例
**Microsoft Exchange ProxyToken (CVE-2021-33766)**
這是一個經典的邏輯/錯誤處理漏洞。當使用者發送特定構造的請求時，後端驗證模組若處理失敗（Exception），系統設計上**錯誤地略過了驗證步驟**，直接將請求轉發給後端伺服器，導致駭客可繞過身分驗證竊取信件。
> [新聞來源：iThome](https://www.ithome.com.tw/news/146461)

### 🛡️ 核心防禦：Fail Safe (失效安全)
1. **實施 Fail Closed (預設拒絕)**：
* **口訣**：「當我不確定時，就說不。」
* 程式碼應設計 `try-catch` 區塊，在 `catch` 發生時，預設變數應為 `allowed = false`。
2. **統一錯誤頁面 (Generic Error Pages)**：
* 對一般使用者只顯示 "500 System Error" 或「系統維護中」。
* **詳細日誌** (Stack Trace) 只能寫入後端 Log Server (供 A09 監控)，絕不能傳回前端。
3. **交易完整性 (Transactional Integrity)**：
* 使用資料庫的 Transaction 機制（ACID 原則），確保操作要嘛全做，要嘛全不做（Atomic），避免因為中途報錯而導致資料不一致。

:::warning
**📝 iPAS 考試重點**
1. **觀念題 - Fail Safe**：
* 題目問：「防火牆當機時，應該阻擋所有連線還是開放所有連線？」
* 答案：為了安全，應選擇 **Fail Closed (阻擋所有/故障閉鎖)**；但在某些強調可用性的場合 (如醫院維生系統) 才會選 Fail Open，但一般資安題預設選 **Fail Closed**。
2. **特徵題**：
* 看到題目圖片是 **「滿滿的程式碼報錯畫面」** ⮕ 秒選 **A10 錯誤處理不當** (或舊觀念中的 A02 配置錯誤，但在 2025 分類更傾向 A10)。
:::

---