115 國安局特考三等 資訊組(選試英文) 網路應用與安全 考古題詳解

核心觀念

本題考查傳統邊界防禦模式與零信任架構的安全理念差異，以及零信任中的三項核心原則：

1. 永不信任（Never Trust）
2. 持續驗證（Continuous Verification）
3. 最小權限（Least Privilege）

此外，題目要求說明零信任環境中的身分驗證、授權邏輯，以及設備健康狀態（Device Posture）如何共同影響存取決策。

---

一、邊界防禦模式與零信任架構

（一）傳統邊界防禦模式

邊界防禦模式以網路位置作為主要信任依據，基本思想是「外部網路不可信，內部網路相對可信」。企業通常透過防火牆、入侵防禦系統、VPN、代理伺服器等設備，在企業內部網路與網際網路之間建立安全邊界。

其典型特徵如下：

• 將網路區分為內部可信區域與外部不可信區域。
• 主要防禦重點集中在網路邊界。
• 使用者進入內部網路後，通常可取得較廣泛的網路可見性與存取權限。
• 驗證常在登入、建立 VPN 連線時完成，後續重新驗證頻率較低。

此模式類似「城堡與護城河」模型：只要使用者成功通過外部邊界，便容易被視為內部可信使用者。

其主要缺點包括：

1. 雲端服務、遠端辦公、行動裝置與 SaaS 應用增加後，企業資源已不再集中於單一內部網路。
2. 攻擊者一旦取得合法帳號或突破邊界，便可能在內部進行橫向移動。
3. 網路位置不能充分代表使用者身分、設備安全程度及實際使用情境。
4. VPN 通常只證明使用者能夠連入網路，不代表其應該存取每一項特定資源。

（二）零信任架構

零信任架構不以網路位置直接推定可信度，其基本理念是：

任何使用者、設備、應用程式或網路連線，在存取特定資源前，都必須經過明確驗證與授權。

零信任並非完全不建立信任，而是不給予「未經驗證的隱含信任」。每一次存取都必須依據身分、設備狀態、資源敏感度、請求情境及風險程度作出決策。

其主要特徵如下：

• 以資源保護為中心，而非僅以網路邊界為中心。
• 將使用者、設備、應用程式與資料視為需要個別保護的對象。
• 身分驗證與授權分開處理。
• 授權採取細粒度控制，只允許使用者取得完成工作所需的權限。
• 依據風險與情境持續重新評估存取資格。
• 即使使用者位於企業內部網路，也不代表其自動可信。

（三）兩者差異比較

比較項目	邊界防禦模式	零信任架構
信任基礎	網路位置與邊界	身分、設備、情境與資源政策
主要防禦範圍	企業網路邊界	每一項應用程式、資料與服務
登入後狀態	通常具有較廣泛的內部信任	每次存取均須符合政策
權限配置	容易形成網路層級的廣泛權限	採取細粒度、資源導向權限
驗證方式	以初次登入或 VPN 驗證為主	持續驗證與動態風險評估
內部攻擊防禦	可能較弱，容易發生橫向移動	透過分段與個別授權降低橫向移動
適用環境	資源集中且邊界清楚的傳統內部網路	雲端、遠端辦公、混合環境與行動裝置

---

二、零信任的三項核心原則

（一）永不信任

「永不信任」是指不因使用者位於內部網路、使用公司帳號、透過 VPN 連線，便自動認定其可信。

系統必須在存取資源前確認：

• 使用者是誰；
• 使用者是否具有合法身分；
• 使用者是否具備存取該資源的必要權限；
• 所使用的設備是否安全；
• 當前請求是否符合時間、地點、網路與風險政策。

因此，「位於內網」只能作為一項情境資訊，不能單獨作為授權依據。

（二）持續驗證

持續驗證是指驗證並非只發生在登入瞬間，而是於工作階段持續監控使用者、設備與存取行為。

系統可依下列事件重新評估：

• 使用者身分或角色發生變更；
• 設備安全更新失敗；
• 偵測到惡意程式或可疑程序；
• 使用者從異常地點或異常網路連線；
• 短時間大量下載敏感資料；
• 使用者請求的資源敏感度提高。

重新評估後，系統可採取要求再次進行多因素驗證、降低權限、暫停工作階段或直接拒絕存取等措施。

（三）最小權限

最小權限原則要求使用者、設備、服務或應用程式，只能取得完成特定任務所需的最低權限，且權限應限縮於必要的資源、操作範圍與使用期間。

例如，財務人員僅需讀取薪資報表，便不應同時取得：

• 修改薪資資料的權限；
• 刪除資料的權限；
• 存取人事管理系統全部資料的權限；
• 長期有效且不受限制的管理員權限。

最小權限可降低帳號遭竊後的損害範圍，也能抑制內部人員或受感染設備進行橫向移動。

---

三、零信任環境下的身分驗證與授權邏輯

（一）傳統模式

傳統模式可能採取以下流程：

核心觀念

本題考查「供應鏈攻擊」的定義、軟體與硬體攻擊案例、攻擊者選擇第三方供應商的原因，以及 SBOM 在資產盤點、漏洞管理與事件應變上的作用。

供應鏈攻擊是指攻擊者不直接入侵最終受害組織，而是滲透其信任的供應商、開發工具、更新機制、物流流程或零組件製造環節，再藉由合法供應鏈將惡意程式、後門、竄改元件或不安全產品送入最終目標環境。

其核心特徵包括：

1. 利用信任關係：最終目標信任供應商及其更新、產品或維護流程。
2. 攻擊上游節點：入侵軟體開發商、代工廠、零組件供應商、物流商或維運商。
3. 擴大攻擊範圍：一個供應商遭入侵，可能同時影響大量客戶。
4. 提高隱蔽性：惡意內容常以合法更新、簽章程式或原廠硬體形式進入環境。

本題不涉及特定法條，應以資通安全、軟體開發生命週期及供應鏈風險管理觀念作答。

解題方法

本題可依「定義—案例—攻擊動機—防禦工具」四段作答：

1. 先界定供應鏈攻擊不是單純的直接入侵，而是利用第三方信任關係。
2. 軟體案例應說明攻擊者如何污染建置流程、更新程式或套件。
3. 硬體案例應說明攻擊者如何在製造、物流或交付前植入惡意元件。
4. 最後從攻擊面、影響範圍、權限與偵測困難度，說明為何攻擊者選擇供應商。
5. 說明 SBOM 如何提供軟體元件清冊，並連結漏洞管理、事件應變與供應商治理。

一、供應鏈攻擊的定義與特性

供應鏈攻擊可分為下列類型：

• 開發環境攻擊：入侵原始碼儲存庫、建置伺服器、CI/CD 平台。
• 軟體更新攻擊：竄改合法更新檔，使客戶自行安裝惡意程式。
• 第三方套件攻擊：污染開源函式庫、套件管理平台或相依元件。
• 硬體製造攻擊：在晶片、主機板、韌體或網路設備中植入後門。
• 物流與維護攻擊：於運送、交付、安裝或遠端維護階段竄改產品。

供應鏈攻擊的危險性在於，惡意內容可能通過原廠簽章、正式更新通道或既有採購流程，使受害者難以辨認其來源不可信。

二、軟體層面的實際案例：SolarWinds Orion 事件

2020 年 SolarWinds Orion 供應鏈攻擊是典型案例。

攻擊者先入侵 SolarWinds 的軟體開發或建置環境，將惡意程式碼植入 Orion 網路管理軟體的建置流程。受污染的版本仍以 SolarWinds 名義發布，並透過正常軟體更新機制及數位簽章散布給客戶。

受害組織安裝更新後，惡意元件可在目標環境中執行，並進一步進行：

• 情報蒐集；
• 橫向移動；
• 權限提升；
• 竊取認證資訊；
• 連線至攻擊者控制的基礎設施。

此案例的關鍵不在於攻擊者逐一破解每個客戶，而在於先污染一個被大量客戶信任的軟體供應商，再利用正式更新管道大規模影響下游組織。

三、硬體層面的實際案例：NSA 物流攔截與網路設備植入

硬體供應鏈攻擊的代表性案例，是公開資料所揭露的美國國家安全局（NSA）物流攔截作法。

其基本模式是在網路設備由製造商交付客戶前，於物流或中途環節攔截設備，植入硬體元件、韌體修改或監控模組，再重新封裝後交付給原定客戶。設備外觀及採購流程仍可能維持正常，但內部已具有額外監控或遠端控制能力。

此類攻擊可能涉及：

• 主機板上加裝惡意晶片；
• 修改網路設備韌體；
• 置入額外通訊模組；
• 改變開機程式或低階控制元件；
• 建立不易由一般防毒軟體發現的永久性後門。

硬體層攻擊通常具有較高持久性，因為惡意元件可能位於作業系統以下，重新安裝作業系統、更新一般應用程式，未必能移除其影響。

四、攻擊者為何鎖定第三方供應商

1. 以較低成本取得較大攻擊範圍

直接攻擊大型政府機關、金融機構或國防組織，通常需要突破多層防禦。若入侵一個具有大量客戶的供應商，即可透過共同產品、更新檔或維護管道，同時觸及大量下游目標。

因此，攻擊效果可概念化為：

$$\text{供應鏈攻擊效益} \approx \text{單一供應商的客戶數} \times \text{每一客戶的可利用程度}$$

2. 利用合法信任關係

最終目標通常會將原廠更新、數位簽章軟體、授權維護工具及正式硬體視為可信來源。攻擊者若能污染這些來源，惡意程式就能以正常程序進入內部網路。

這種攻擊不必直接繞過所有防火牆，也能借用既有的信任機制。

3. 供應商常具有較高權限

第三方軟體、代理程式、維護工具及遠端管理系統，通常具有下列權限：

• 系統管理員權限；
• 網路管理權限；
• 存取內部伺服器的權限；
• 讀取設定檔及認證資訊的權限；
• 執行更新或安裝程式的權限。

因此，供應商管道一旦遭污染，攻擊者可直接取得較高的初始權限。

4. 供應商的資安防護可能弱於最終目標

大型政府機關或金融機構通常投入大量資源進行監控與防禦，但中小型供應商可能缺乏：

• 建置環境隔離；
• 多因素驗證；
• 程式碼審查；
• 簽章金鑰保護；
• 第三方依賴管理；
• 完整的日誌與偵測能力。

攻擊者因此可選擇防護較弱的上游節點，達成攻擊高價值下游目標的目的。

5. 更容易隱藏攻擊來源

受害者初期可能認為異常行為來自合法軟體、合法更新或原廠設備，導致調查方向延遲。供應商本身也可能無法立即判斷是建置環境遭污染，造成攻擊持續較久。

核心觀念

本題考查企業網路邊界防護設備的分工，以及由傳統封包過濾逐步發展至應用層安全控管的概念。三者均可分析網路流量，但在「判斷依據」、「部署位置」及「是否主動阻擋」方面不同：

• 防火牆（Firewall）：以存取控制為核心，決定流量能否通過。
• 入侵偵測系統（IDS）：以偵測與告警為核心，發現攻擊後通知管理者。
• 入侵防禦系統（IPS）：以即時阻擋為核心，發現攻擊後主動採取防禦措施。
• 下一代防火牆（NGFW）：將傳統防火牆、應用程式識別、入侵防禦及其他安全功能整合於單一平台。

本題屬資訊安全與網路設備功能比較題，不涉及特定法條或計算公式。

解題方法

可依序從三個面向作答：

1. 功能定位：設備主要解決什麼問題。
2. 運作方式：依據哪些資訊進行判斷，部署於何處。
3. 回應行為：發現異常後是放行、記錄、告警，還是直接阻擋。

最後再說明 NGFW 如何整合三者功能，並指出其相較於傳統防火牆的核心提升在於「能辨識應用程式與使用者，不只查看 IP 與連接埠」。

一、防火牆（Firewall）

1. 功能定位

防火牆是網路存取控制設備，主要目的在於依據既定安全政策，控制不同網路區域間的流量。例如：

• 允許內部使用者存取外部網站。
• 禁止外部直接連入內部伺服器。
• 僅允許特定來源 IP 存取特定服務。
• 將內部網路、伺服器區及訪客網路相互隔離。

防火牆的重點是「這個連線是否符合安全政策」，而非專門判斷封包內容是否為攻擊。

2. 運作方式

傳統防火牆可依據下列資訊進行過濾：

• 來源 IP 位址
• 目的 IP 位址
• 通訊協定，例如 TCP、UDP、ICMP
• 來源埠號
• 目的埠號
• 連線狀態
• 網路介面或安全區域

早期封包過濾防火牆主要依據封包標頭判斷；狀態檢查防火牆（Stateful Firewall）則會維護連線狀態表，辨識封包是否屬於既有且合法的連線。

例如，內部使用者先向外部網站建立 TCP 連線，防火牆可允許回應封包返回；若外部主機未經內部要求，直接建立新的連入連線，防火牆即可依政策予以拒絕。

3. 回應行為

防火牆的回應通常包括：

• Allow：允許通過。
• Deny：拒絕通過，但不一定回覆對方。
• Reject：拒絕通過，並回覆拒絕訊息。
• Log：記錄連線或違規事件。
• NAT：進行網路位址轉換，以隱藏內部位址或節省公有 IP。

防火牆主要是「依規則管制」，即使某封包內容含有惡意程式碼，只要傳統規則未涵蓋該情形，仍有可能被視為合法流量而放行。

二、入侵偵測系統（IDS）

1. 功能定位

IDS 的主要功能是監控網路或主機活動，辨識疑似入侵、攻擊及違反安全政策的行為，並發出告警。

IDS 著重於：

• 偵測可疑活動。
• 分析攻擊特徵。
• 保存事件紀錄。
• 通知管理者或安全資訊事件管理系統（SIEM）。

IDS 本身通常不負責直接阻斷連線，因此定位偏向「監控、分析與告警」。

2. 運作方式

IDS 常見的偵測方法如下：

（1）特徵式偵測

將流量或事件與已知攻擊特徵比對，例如：

• 已知惡意程式碼樣式。
• 特定 SQL Injection 字串。
• 已知掃描工具行為。
• 特定漏洞利用封包格式。

優點是對已知攻擊通常具有較高辨識率；缺點是難以辨識全新的攻擊或經過變形的攻擊。

（2）異常式偵測

先建立正常流量或正常使用行為模型，再判斷偏離程度。例如：

• 平時不使用的連接埠突然出現大量連線。
• 單一帳號在短時間內從多個地點登入。
• 內部主機突然大量掃描其他主機。

優點是有機會發現未知攻擊；缺點是正常行為變動時，容易產生誤報。

（3）協定分析與行為分析

檢查通訊協定是否符合標準，以及連線行為是否具有攻擊特徵。例如封包宣稱為 HTTP 流量，但實際內容出現不符合協定的異常資料。

IDS 可分為：

• 網路型 IDS（NIDS）：監控網路流量。
• 主機型 IDS（HIDS）：監控主機上的檔案、程序、登入及系統紀錄。

3. 部署與回應行為

NIDS 常透過網路分流、交換器鏡像埠或網路探針取得流量，因此通常不直接位於主要流量轉送路徑上。這種部署方式不會明顯增加網路延遲，但也使 IDS 通常只能告警，無法直接切斷攻擊連線。

IDS 發現疑似攻擊後，常見回應包括：

• 發出告警。
• 記錄來源、目的、時間及攻擊特徵。
• 將事件送至 SIEM。
• 通知管理者。
• 由其他設備或管理者後續處理。

因此，IDS 的關鍵字是「偵測但不主動阻擋」。

三、入侵防禦系統（IPS）

1. 功能定位

IPS 是具備主動防禦能力的入侵偵測系統，除分析流量外，還會在攻擊流量抵達受保護主機前採取阻擋措施。

IPS 的定位是：

• 即時偵測攻擊。
• 主動阻擋惡意流量。
• 降低漏洞遭利用的風險。
• 對連線或來源採取動態管制。

2. 運作方式

IPS 通常採用 Inline 模式，直接部署於流量必經路徑。所有流量先經過 IPS 分析，判斷為合法後才轉送至目的端。

IPS 可使用：

• 特徵式偵測。
• 異常式偵測。
• 協定解碼。
• 深度封包檢測（Deep Packet Inspection）。
• 連線狀態分析。
• 漏洞與攻擊行為比對。

3. 回應行為

IPS 偵測到攻擊後，可採取下列措施：

核心觀念

本題考查緩衝區溢位的成因、記憶體配置差異、任意程式碼執行流程，以及現代作業系統與編譯器的防護機制。

1. 緩衝區溢位定義

緩衝區（Buffer）是程式在記憶體中配置的一段固定大小區域，用來暫存字串、輸入資料或中間結果。若程式未正確檢查輸入長度，使寫入資料超過緩衝區容量，額外資料便會覆寫相鄰記憶體內容，形成緩衝區溢位。

例如：

char buf[8];
strcpy(buf, input);

若 input 長度超過 7 個字元，再加上字串結尾的 \0，便可能覆寫 buf 以外的記憶體。

其根本原因是：

1. 輸入長度未受到限制。
2. 程式未正確檢查邊界。
3. 不安全函式未考慮目的緩衝區大小。
4. 記憶體中的資料與控制資訊排列相鄰，使溢位可能改變程式流程。

緩衝區溢位造成的結果包括：

• 程式崩潰。
• 資料遭竄改。
• 權限提升。
• 拒絕服務。
• 任意程式碼執行（Arbitrary Code Execution, ACE）。

---

堆疊溢位與堆積溢位的差異

1. 堆疊溢位（Stack Overflow）

堆疊通常存放：

• 函式區域變數。
• 函式參數。
• 返回位址。
• 保存的暫存器。
• Stack Canary 等控制資料。

典型配置可表示如下：

高位址
返回位址
保存的框架指標
區域變數
char buffer[]
低位址

當輸入資料超過區域緩衝區大小，可能依序覆寫：

1. 相鄰區域變數。
2. Stack Canary。
3. 保存的框架指標。
4. 函式返回位址。

若攻擊者能控制返回位址，函式執行 return 時，處理器便可能跳至攻擊者指定的位置，進而改變控制流程。

堆疊溢位的特徵是：

• 常發生於區域陣列或函式內部緩衝區。
• 容易直接影響返回位址。
• 攻擊流程通常較具規律。
• 常受到 Stack Canary、ASLR、DEP/NX、Shadow Stack 等機制防護。

2. 堆積溢位（Heap Overflow）

堆積是程式執行期間透過 malloc、calloc、new 等方式動態配置的記憶體區域，通常存放：

• 動態字串。
• 物件。
• 陣列。
• 結構資料。
• 函式指標或虛擬函式表指標。

若寫入資料超過堆積緩衝區大小，可能覆寫：

• 相鄰物件的欄位。
• 物件中的函式指標。
• C++ 物件的 vtable 指標。
• 堆積管理器的 metadata。
• 其他使用者資料。

堆積溢位的特徵是：

• 發生於動態配置記憶體。
• 覆寫目標通常不固定，取決於配置器與物件排列。
• 可造成資料竄改、函式指標劫持或記憶體管理結構破壞。
• 常與 Use-After-Free、Double Free 等記憶體錯誤結合。
• 利用難度通常受堆積配置器、物件配置順序及指標位址影響。

3. 兩者比較

比較項目	堆疊溢位	堆積溢位
發生位置	函式呼叫堆疊	動態配置的堆積區域
常見目標	返回位址、保存框架指標	物件欄位、函式指標、vtable、metadata
控制流程方式	覆寫返回位址	覆寫函式指標、物件指標或其他控制資料
配置型態	編譯時或函式進入時建立	執行期間動態配置
利用特性	記憶體排列較規律	配置位置與排列較不固定
常見防護	Canary、ASLR、DEP/NX、Shadow Stack	ASLR、Heap Hardening、metadata 防護、記憶體安全語言

---

解題方法：從資料破壞到控制流程劫持

本題第二部分應依照下列攻擊鏈說明：

$$\text{輸入越界} \rightarrow \text{覆寫控制資料} \rightarrow \text{取得指令指標控制權} \rightarrow \text{執行攻擊者選定的指令}$$

1. 找出可溢位的輸入點

攻擊者先尋找程式中未進行長度檢查的輸入介面，例如：

• 網路封包欄位。
• HTTP 參數。
• 檔案格式欄位。
• 命令列參數。
• 使用者名稱或密碼欄位。
• 不安全的字串複製函式。

攻擊者製作超過預期長度的輸入，使資料寫出原本緩衝區的邊界。

2. 覆寫控制資料

若為堆疊溢位，攻擊者可能覆寫返回位址，使函式返回時將指令指標 EIP 或 RIP 設為攻擊者指定的位址。

若為堆積溢位，攻擊者可能改寫：

• 函式指標。
• C++ vtable 指標。
• 回呼函式位址。
• 物件中的長度或指標欄位。
• 堆積配置器的控制資料。

3. 將控制流程導向攻擊內容

傳統攻擊會將機器碼放入可控緩衝區，並將返回位址指向該區域。這段機器碼常稱為 Shellcode，可執行開啟命令列、建立遠端連線或下載其他惡意程式等動作。

現代環境通常禁止資料區執行，因此攻擊者常採用：

• Return-Oriented Programming（ROP）。
• Jump-Oriented Programming（JOP）。
• Call-Oriented Programming（COP）。

ROP 不需注入完整的新程式碼，而是串接程式或函式庫中既有的短指令片段（gadgets），透過多個返回位址組合出所需操作，以繞過不可執行記憶體防護。

4. 達成任意程式碼執行

當攻擊者能控制指令指標，並能安排暫存器、堆疊與參數內容，即可使程式執行攻擊者選定的指令。若程式具有系統管理權限，攻擊結果可能進一步擴大為：

• 權限提升。
• 讀取機密檔案。
• 建立後門帳號。
• 植入惡意程式。
• 控制整部主機。

因此，ACE 的關鍵不只是「資料被覆寫」，而是「覆寫結果能影響程式控制流程，並讓處理器執行攻擊者安排的指令」。

---

核心觀念

本題考查跨站腳本攻擊（Cross-Site Scripting, XSS）的基本原理、攻擊型態，以及 Session Cookie 外洩方式與防禦機制。

XSS 的核心不是攻擊者直接入侵伺服器，而是將惡意 JavaScript 植入可信任的網站頁面，使受害者的瀏覽器在該網站的安全脈絡下執行該程式。由於瀏覽器會將程式視為網站本身提供的內容，因此惡意程式可讀取頁面資料、操作 DOM、發送請求，甚至竊取未受保護的 Cookie。

XSS 通常發生於下列情況：

1. 應用程式接收使用者輸入。
2. 伺服器或前端未妥善過濾、編碼輸入內容。
3. 惡意內容被插入 HTML、JavaScript、URL 或其他可執行脈絡。
4. 使用者瀏覽受污染的頁面時，瀏覽器執行惡意腳本。

---

解題方法

本題可分成兩部分作答：

1. 先說明 XSS 的共同攻擊原理，再比較儲存型與反射型。
2. 接著說明 Cookie 竊取流程，最後列出防禦機制及其作用原理。

作答時應掌握「輸入未妥善處理 → 惡意腳本進入頁面 → 瀏覽器代為執行 → 讀取資料或代表使用者發送請求」這條完整攻擊鏈。

---

一、XSS 攻擊原理

XSS 是利用網站對使用者輸入資料驗證、過濾或輸出編碼不足的缺陷，將惡意腳本嵌入網頁。當其他使用者開啟該頁面時，瀏覽器會把惡意內容當成網站程式的一部分執行。

攻擊者可藉此進行：

• 竊取未設定 HttpOnly 的 Cookie。
• 讀取頁面上的個人資料或表單內容。
• 偽造使用者操作，例如修改帳號設定、發送訊息。
• 將使用者重新導向至釣魚網站。
• 監控鍵盤輸入或竄改頁面內容。
• 以受害者身分向網站發送請求。

XSS 的本質是「在受信任的網站脈絡中執行不受信任的腳本」。因此，即使攻擊程式碼原本來自攻擊者，瀏覽器仍可能將其視為該網站的同源內容。

---

二、儲存型與反射型 XSS 的差異

1. 儲存型 XSS（Stored XSS）

儲存型 XSS 又稱持久型 XSS。攻擊者將惡意腳本送入網站後，網站未經適當處理便儲存於資料庫或其他後端儲存位置，例如：

• 討論區文章。
• 留言內容。
• 使用者個人資料。
• 商品評論。
• 私人訊息。

當其他使用者瀏覽包含該資料的頁面時，伺服器會將惡意腳本一併輸出，瀏覽器便執行該腳本。

其特性如下：

• 惡意內容會留存在網站系統中。
• 不需要每次都誘導受害者點擊特殊網址。
• 只要受害者瀏覽受污染頁面，就可能遭受攻擊。
• 影響範圍通常較廣，適合大量攻擊。
• 風險通常高於單次反射型 XSS。

2. 反射型 XSS（Reflected XSS）

反射型 XSS 又稱非持久型 XSS。攻擊者將惡意內容放在 HTTP 請求中，例如查詢字串或表單參數，伺服器未經適當編碼便直接將該內容反射回回應頁面。

常見流程為：

1. 攻擊者製作含有惡意參數的網址。
2. 透過電子郵件、社群訊息或釣魚頁面誘導受害者點擊。
3. 伺服器接收參數並將其直接嵌入回應內容。
4. 受害者瀏覽器執行反射回來的惡意腳本。

其特性如下：

• 惡意內容通常不會永久儲存在伺服器。
• 必須誘導受害者發出特定請求。
• 攻擊效果通常與單一請求或特定連結有關。
• 常見於搜尋結果頁、錯誤訊息頁與查詢功能。

3. 比較表

比較項目	儲存型 XSS	反射型 XSS
惡意內容位置	儲存於資料庫或伺服器	位於請求參數中
是否持久存在	是	否
受害者觸發方式	瀏覽受污染頁面	點擊或存取惡意連結
攻擊範圍	可影響多名使用者	通常針對特定受害者
常見位置	留言、文章、評論	搜尋欄、錯誤頁、查詢參數
典型風險	大規模散播	社交工程與釣魚攻擊

補充而言，DOM 型 XSS 主要由前端 JavaScript 不安全地處理來源資料所造成，惡意內容可能不必經過伺服器直接反射或儲存，即可在瀏覽器端形成漏洞。

---

三、利用 XSS 竊取 Session Cookie 的方式

Session Cookie 通常用來讓伺服器辨識使用者目前的登入狀態。若攻擊者取得有效的 Session Cookie，便可能在一定期間內冒用該 Cookie 發送請求，形成 Session Hijacking（工作階段劫持）。

典型攻擊流程如下：

1. 攻擊者將惡意 JavaScript 植入網站。
2. 受害者登入網站並取得 Session Cookie。
3. 受害者瀏覽含有惡意腳本的頁面。
4. 惡意腳本在受害者瀏覽器中執行。
5. 若 Session Cookie 沒有設定 HttpOnly，腳本可透過瀏覽器的 Cookie API 讀取該 Cookie。
6. 惡意程式將 Cookie 傳送至攻擊者控制的伺服器。
7. 攻擊者在其他環境中帶入該 Cookie，冒用受害者的登入身分。

概念上，惡意腳本會嘗試讀取目前網站可由 JavaScript 存取的 Cookie，例如：

document.cookie

接著將取得的資料送往外部伺服器。實際上能否讀到 Session Cookie，取決於 Cookie 的安全屬性、瀏覽器同源政策及網站的其他防護措施。

必須注意：

• 設定 HttpOnly 的 Cookie 無法由一般 JavaScript 透過 document.cookie 讀取。
• HttpOnly 並不會阻止 XSS 本身，也不會阻止惡意腳本代表使用者向同一網站發送請求。
• 即使 Cookie 無法被讀出，XSS 仍可能直接操作目前頁面、讀取帳戶資料，或代替使用者執行功能。
• 若 Session Cookie 未設定 Secure，在非加密連線環境下可能遭攔截。