什麼是 LDAP Injection？其運作方式與防範方法

什麼是 LDAP Injection？

LDAP injection 是一種伺服器端攻擊，會利用 Web 應用程式以未經淨化的使用者輸入來建構 Lightweight Directory Access Protocol 查詢的弱點。當您的應用程式在將特殊字元納入 LDAP 查詢之前，未能正確中和這些字元時，攻擊者便可操控這些查詢，以繞過驗證、擷取敏感的目錄資料，或修改 LDAP 樹狀結構中的項目。

LDAP 目錄位於企業身分識別基礎架構的核心。它們儲存使用者認證、群組成員資格、存取控制清單、組織結構，以及服務帳戶詳細資料。只要一次成功的 LDAP injection 攻擊，就可能暴露此儲存庫，讓攻擊者取得您驗證基礎架構的關鍵控制權。

MITRE 將此弱點歸類為 MITRE CWE-90: LDAP Query 中使用之特殊元素的不當中和。OWASP 將其列於 OWASP Injection 以及更新後的 OWASP Injection 類別之下。此弱點與 SQL injection具有相同的根本原因，但其目標是本質上不同且通常影響更為重大的系統：管理整個組織中誰可存取何種資源的目錄服務。

要了解 LDAP injection 的運作方式，需要先了解攻擊者所利用的查詢語法。

LDAP Injection 如何運作？

LDAP 搜尋篩選器遵循 LDAP syntax中定義的特定語法。篩選器使用波蘭表示法（前置表示法），其中一個簡單的驗證查詢如下所示：

& 運算子會執行布林 AND。括號用於分組條件。* 萬用字元可比對任何值。這些中繼字元，連同 | (OR), ! (NOT), =, ~=, >=, <=, and () 分組運算子，共同構成注入面。

當開發人員透過串接方式，將使用者輸入直接納入查詢字串來建構篩選器時，這些中繼字元就會成為武器。若登入表單將使用者名稱直接插入類似 (&(uid=INPUT)(userPassword=HASH)), 的篩選器中，提交精心構造中繼字元的攻擊者便可徹底改變篩選器邏輯：繞過驗證、傳回所有目錄項目，或逐字元擷取資料。

攻擊者使用的具體技術取決於 LDAP injection 的類型。

LDAP Injection 的類型

LDAP injection 有數種不同形式，每一種都針對應用程式與目錄互動方式的不同面向。攻擊者採用的類型取決於應用程式的行為、查詢內容，以及攻擊者能從回應中觀察到什麼。

搜尋篩選器注入

請看這段存在弱點的 Java 程式碼：

如果攻擊者提交 user=*，產生的篩選器就會變成 (cn=*)，這會比對目錄中每個具有 cn 屬性的物件。您的應用程式將傳回整個使用者目錄，而不是單一筆記錄。

驗證繞過

LDAP 驗證流程是後果最嚴重的注入目標。如下這類存在弱點的登入篩選器：

此篩選器可透過將 )(uid=))(|(uid=* 注入為使用者名稱來繞過。產生的篩選器會被評估為永遠為真，讓攻擊者取得 LDAP 樹狀結構中第一位使用者的已驗證狀態，通常是管理員帳戶。The 測試指南 將此記錄為 SQL injection authentication bypass techniques 的直接對應類比。

Blind LDAP Injection

當應用程式不直接顯示查詢結果時，攻擊者會使用差異化回應來擷取資料。透過注入如 (attribute=a*), (attribute=b*) 之類的篩選條件，並觀察應用程式是否回傳結果或空白頁面，他們便能逐字元擷取屬性值。於 Black Hat 論文中發表的研究證明，限制顯示資訊的用戶端篩選器無法防止 blind injection techniques。

Distinguished Name 操作

LDAP 具有不同的跳脫內容脈絡，混淆它們會產生注入向量。搜尋篩選器需要依 RFC 4515 進行跳脫 (*→\2a, (→\28, )→\29)。Distinguished Names (DNs) 需要依 RFC 2253 進行跳脫 (\, #, +, <, >, ,, ;, ", =)。將錯誤的跳脫內容脈絡套用到錯誤的欄位，即使您認為已處理該問題，仍會使您的應用程式暴露於弱點之中。

這些攻擊類型具有共同的根本原因，而且其層次比語法更深。

LDAP Injection 的成因

LDAP injection 弱點源自編碼實務、程式庫限制與基礎架構錯誤設定的組合。每個根本原因都會形成一條獨立的利用路徑。

• 直接字串串接。 幾乎所有 LDAP injection 弱點的直接原因，都是在應用程式層將使用者可控制的資料直接串接到 LDAP 篩選器字串中。LDAP 程式庫歷來缺乏內建的參數化查詢支援，因此需要開發人員遵循 手動指引 來安全地建構查詢。參數化介面雖然存在，但需要刻意採用。
• 特殊字元管理不當。 嘗試進行輸入驗證的應用程式，通常會實作不完整的拒絕清單，而遺漏危險字元。若拒絕清單封鎖 * 和 (，卻遺漏 ) 或 NUL 位元組，仍會留下可被利用的缺口。 MITRE CWE-90 將 LDAP injection 識別為此失敗所導致的結果，這表示注入弱點是直接源自對特殊字元管理不當的根本問題。
• 跳脫內容脈絡混淆。  LDAP 備忘單 記錄指出，將搜尋篩選器跳脫套用至 DN 欄位，或將 DN 跳脫套用至搜尋篩選器欄位，會因錯誤的內容脈絡選擇而產生注入向量。若您的開發人員知道需要跳脫，卻選擇了錯誤的函式，您的應用程式仍然存在弱點。
• 匿名與未驗證的 bind 設定。 設定為允許匿名 bind 的 LDAP 伺服器，會讓攻擊者完全繞過 bind 驗證。
• LDAP 廣泛用於驗證。 LDAP 作為企業環境驗證骨幹的角色，意味著針對登入流程的注入會產生後果最嚴重的結果：取得對企業範圍資源的已驗證存取權。 attack surface 依架構設計即涵蓋整個企業範圍。

這些成因結合後，會造成遠遠超出單一遭入侵查詢的風險。

LDAP Injection 的影響與風險

LDAP injection 攻擊可能造成數種類別的業務影響，而且每一類的嚴重程度都會升高。

驗證繞過

永遠為真的篩選器注入會立即授予已驗證存取權。OpenText Enterprise Server 中的 CVE-2023-4501 允許在任何有效使用者名稱下成功通過驗證，而不論密碼是否正確，且也可能在無效使用者名稱搭配任何密碼的情況下成功。這影響了部署於金融服務、保險與政府領域的企業 COBOL 開發與執行階段環境。

敏感資料外洩

LDAP 目錄包含使用者認證資料、密碼雜湊、電子郵件地址、組織階層、群組成員資格、ACL、電腦帳戶，以及 安全性識別碼。一則 CISA 公告記錄了一次單一 LDAP 查詢，從企業目錄中擷取有關使用者、電腦、群組、ACL、OU 與 GPO 的資訊。

權限提升

成功的注入可授予未經授權查詢的權限，並允許修改 LDAP 樹中的內容。Parse Server 中的 CVE-2026-31828 允許已驗證的低權限使用者透過 LDAP 篩選器注入提升至任何受限制群組。

阻斷服務

CVE-2025-12764（pgAdmin）展示了將 LDAP 注入武器化，以迫使 DC/LDAP 伺服器與用戶端處理異常大量的資料，導致目錄基礎架構發生阻斷服務，並引發連鎖式驗證失敗。

促成橫向移動

LDAP 列舉會為 Active Directory 偵察提供資料。CISA 紅隊公告記錄指出，LDAP 資料可用於對使用者、電腦、群組、ACL、OU 和 GPO 進行對應，而這些全都是以下項目的輸入： 橫向移動 規劃。經評估的企業對此活動完全沒有可視性。

OWASP 在其 OWASP 架構中，將注入的可利用性評為 3（容易），技術影響評為 3（嚴重）。LDAP 注入也會帶來直接的合規後果： PCI DSS 6.5.1 明確將 LDAP 注入與 SQL 和 XPath 注入並列為必要的評估目標。

了解影響有助於您排定防禦優先順序，但您也需要確切知道攻擊者如何發現並將這些弱點武器化。

攻擊者如何利用 LDAP 注入

攻擊者會遵循結構化的方法來尋找並利用 LDAP 注入弱點，從偵察一路推進到完整的認證資料擷取。

步驟 1：識別整合 LDAP 的進入點

攻擊者會識別可能查詢 LDAP 後端的應用程式功能。根據 SANS LDAP 部落格，LDAP 可用於管理、驗證，以及從目錄資料庫查詢物件。登入表單、使用者搜尋頁面、密碼重設流程、企業目錄查詢，以及 VPN 閘道入口網站，都是可能的攻擊面。

步驟 2：探測注入點

The OWASP LDAP 測試 指示測試人員插入字元 (, |, &, * 以檢查是否有差異化回應。錯誤訊息、空白結果集或應用程式行為改變，都可確認存在弱點參數。

步驟 3：推斷篩選器結構

在沒有原始碼的情況下，攻擊者會透過模糊測試推斷 LDAP 篩選器結構。SANS 指出：「在滲透測試期間，您不太可能擁有原始碼來查看這些陳述式。在這些情況下，可能必須採用模糊測試與偵察。」

步驟 4：製作注入酬載

常見酬載包括：

• 萬用字元注入 (*) 以擷取所有目錄項目
• 永遠為真的篩選器 ()(uid=))(|(uid=*) 以繞過驗證
• 以 OR 為基礎的屬性注入 ()(department=it)(|(cn=) 以跨多個屬性蒐集認證資料
• Null object class 終止 (*)(objectClass=*))(& (objectClass=void) 以建立可靠的布林預言機，用於盲式擷取

具體酬載取決於攻擊者在偵察期間推斷出的篩選器結構。

步驟 5：透過攻擊鏈升級

OWASP 與MITRE ATT&CK來源中記錄的典型攻擊鏈，會遵循以下進程：

1. 使用永遠為真的篩選器繞過登入
2. 透過以 OR 為基礎的注入擷取網域認證資料
3. 透過 ldapmodify 建立網域帳戶（ATT&CK T1136.002）
4. 傾印 NTDS.dit 以進行離線憑證破解（ATT&CK T1003.003）

盲式 LDAP 注入可形成一條平行攻擊鏈，攻擊者可使用 (attribute=*) 探測來列舉結構描述屬性，接著逐字元擷取值，包括密碼雜湊、群組成員資格與安全性識別碼。

這些利用模式會影響廣泛的組織與應用程式類型。

哪些對象會受到 LDAP 注入影響？

任何依賴 LDAP 支援驗證的組織，都在結構上暴露於此弱點。OWASP 指出，注入弱點「非常普遍，尤其是在 舊版程式碼。」

曝險最高的應用程式類型包括：

• 採用 LDAP 支援驗證的 Web 應用程式（登入入口網站、SSO 系統）
• 使用字串串接 LDAP 查詢的舊版企業應用程式
• 自助式密碼重設與員工目錄入口網站
• VPN 閘道與遠端存取入口網站
• 工業控制系統管理平台
• 桌面應用程式（OWASP Desktop App Security Top 10 將 LDAP 注入列於 DA1 Injections）

風險集中的產業包括：

• 醫療保健：採用 LDAP 支援的 EHR 與臨床系統，若弱點未修補，將面臨 HIPAA 執法風險，HHS 記錄了 HHS breach data，涵蓋 2018 年至 2022 年間的大型資料外洩事件。
• 金融服務： 在此產業中，注入仍是與身分識別相關企業系統的重要攻擊面。
• 政府與關鍵基礎設施： CISA 已記錄政府環境與 ICS 能源產業平台中的主動利用情況。
• 軟體與科技：開源後端、資料庫工具與開發平台持續產生新的 LDAP 注入 CVE。

LDAP 注入會影響廣泛的軟體，涵蓋企業 COBOL 環境、資料庫管理工具、能源產業平台與開源後端。這些並非假設性風險；近期事件已證實其存在。

LDAP 注入的真實世界案例

以下案例說明 LDAP 注入如何在政府網路、企業平台與開源工具中發生。

CISA Red Team：LDAP 可視性為零的企業（2024）

一項 CISA assessment 發現，受評估企業「未對異常 LDAP 流量進行監控」。該團隊查詢 LDAPS，以蒐集有關使用者、電腦、群組、ACL、OU 與 GPO 的資訊。CISA 明確表示，非特權使用者從 Linux 網域主機查詢 LDAP「本應提醒網路防禦人員」。

OpenText Enterprise Server：完整驗證繞過（CVE-2023-4501）

此弱點允許驗證在不論密碼為何的情況下，只要使用任何有效使用者名稱即可成功，甚至也可能使用無效使用者名稱成功。它影響部署於金融服務、保險與政府大型主機整合中的企業 COBOL 開發與執行階段環境。

Ivanti EPMM：threat actors 傾印 LDAP 憑證（2025）

在 2025 年 5 月概念驗證公開後，threat actors 取得對 Ivanti EPMM 伺服器的存取權，並且 傾印了 LDAP 憑證。CISA 於 2025 年 5 月 19 日將其底層弱點加入 KEV 目錄。

Redash：可啟用密碼噴灑的 LDAP 注入（CVE-2020-36144）

GitHub Security Lab 記錄指出，Redash LDAP 驗證中的電子郵件欄位在格式化 LDAP 篩選器查詢字串時未進行逸出處理，使未經驗證的攻擊者能以單一請求暴力破解所有使用者的密碼。

這些事件橫跨數十年的 LDAP 安全挑戰。

LDAP 注入時間軸與歷史

LDAP 注入作為一種已知弱點類別，已存在超過二十年；從 1990 年代末期至今，其正式分類與持續的 CVE 揭露從未間斷。

• 通訊協定起源。 X.500 Directory Access Protocol (DAP) 由 ITU-T 開發。LDAP v1 出現在 RFC 1487，v2 出現在 RFC 1777，而 v3 出現在 RFC 2251，至今仍是企業環境中使用的版本。
• 首次記錄的問題. CVE-1999-0895 記錄了 Checkpoint FireWall-1 V4.0 中一項早期的 LDAP 驗證安全問題。
• 正式分類. OWASP 正式將 LDAP injection 記錄為一種獨立的攻擊類別。2007 年 OWASP Top 10 將其歸類於 A2，Injection Flaws。
• 盲注入研究. Alonso 等人在 Black Hat Europe 發表了系統性的 盲式 LDAP 研究，展示如何逐字元擷取資料。
• OWASP 優先級高峰。 OWASP Top 10 2017 將 Injection 排名為 A1，也就是排名第一的 Web 應用程式風險，並明確點名 LDAP injection。
• ICS 鎖定. CVE-2018-14805 (ABB eSOMS) 將 LDAP injection 帶入能源產業的 ICS 領域。
• 企業平台鎖定. ForgeRock OpenAM、OpenLDAP 與 OpenText Enterprise Server 顯示其對企業環境持續造成影響。
• 近期揭露。 近年來的新 CVE 影響 Apache Druid、WatchGuard Fireware、WeKan、Parse Server、Dell PowerMax 與 pgAdmin。

新的 CVE 持續出現，這使得持續監控成為實務上的必要要求。

如何偵測 LDAP Injection

您需要跨應用程式、目錄與網路層級進行分層監控。

應用程式層指標

監控使用者輸入欄位中的 LDAP 中繼字元：*, (, ), \，以及驗證與搜尋參數中的 NUL 位元組。留意異常龐大的 LDAP 結果集，這可能表示萬用字元注入導致傳回所有目錄項目。格式錯誤的查詢後立即驗證成功，表示驗證繞過模式。

LDAP 伺服器層指標

尋找包含 )( 或 |( 序列的篩選器結構，這表示篩選器群組遭到操控。透過 (objectClass=*) 或 (cn=*) 傳回所有項目的查詢，表示可能存在萬用字元列舉。匿名 bind 後接著進行廣泛搜尋作業，表示未經驗證的偵察嘗試。

SIEM 與事件記錄監控

對於 Active Directory 環境，有兩個 Windows Event ID 至關重要：

• Event ID 4662: 對 AD 物件執行的作業。監控 Write Property、Control Access、DELETE、WRITE_DAC 與 WRITE_OWNER 動作。
• Event ID 1644: 高成本或低效率的 LDAP 查詢，注入嘗試通常會產生這類查詢。

根據 NCC Group 指南：「在記錄中尋找異常的搜尋篩選器。攻擊者經常使用特定篩選器來列舉使用者、群組與電腦。」

行為關聯模式

跨資料來源進行關聯，以找出注入活動：

• 來自單一來源 IP 的高 LDAP 查詢量（注入工具）
• 循序屬性列舉：uid=a*, uid=b*（盲注入擷取）
• 密碼失敗後立即登入成功（驗證繞過確認）
• 非特權 Linux 網域主機執行大量 LDAP 查詢（這正是 CISA 記錄為未被偵測的確切模式）

跨來源關聯這些訊號，比起任何單一指標，都能讓您更清楚掌握進行中的注入活動。

WAF 層級監控

OWASP ModSecurity Core Rule Set 在 REQUEST-921-PROTOCOL-ATTACK.conf, 中包含規則 ID 921200，該規則以 CRITICAL 嚴重性和 Paranoia Level 1（預設啟用）為目標偵測 LDAP 注入。此規則會檢查請求 Cookie、參數名稱、參數值及 XML 主體中的 LDAP 篩選器中繼字元模式。

若沒有適當的防護控制，發現可疑活動仍然不足夠。

如何防止 LDAP 注入

預防需要採取涵蓋程式碼、組態與基礎架構層的縱深防禦方法。

程式碼層級防禦

• 使用參數化 LDAP 查詢。 最有效的防禦方式是將使用者輸入作為參數傳遞，而不是將其串接到篩選器字串中：

• 套用符合情境的跳脫處理。 針對正確的 LDAP 情境使用正確的跳脫函式。對於搜尋篩選器（RFC 4515），請將 * 跳脫為→\2a, (→\28, )→\29, \→\5c, NUL→\00。對於 Distinguished Names（RFC 2253），請跳脫 \, #, +, <, >, ,, ;, ", =，以及前導/尾隨空白。

特定語言的實作包括：

• 實作允許清單驗證。 在執行任何 LDAP 作業之前，先根據預期模式驗證輸入。拒絕包含該欄位中不應出現之中繼字元的輸入。依據 OWASP 備忘單，在驗證前先正規化輸入（Unicode 正規化）。

基礎架構強化

• 停用匿名與未驗證繫結。 這項單一措施可消除多個重大漏洞背後的根本原因。
• 使用 LDAPS（連接埠 636）。 依據 NIST SP 1800-16 停用明文 LDAP（連接埠 389）。
• 對 LDAP 繫結服務帳戶套用最小權限 ACL。 將其限制為僅能執行所需的作業與目錄子樹。
• 依據 NIST SP 1800-18B 將 LDAP 基礎架構 與一般網路存取區隔.

這些控制措施可減少攻擊者在到達您的 LDAP 基礎架構後可利用的攻擊面。

CI/CD 管線整合

將靜態分析 (SAST) 與動態分析 (DAST) 整合至您的開發管線中。  OWASP Top 10 建議納入 SAST、DAST 與 IAST 工具，以識別 注入缺陷，並在正式部署前完成識別。Semgrep 的 taint analysis 模式可使用針對 LDAP 查詢建構的自訂規則，在未經淨化的情況下追蹤從來源到匯點的不受信任輸入。

當有適當工具支援時，這些預防措施的效果最佳。

偵測與預防工具

有效的 LDAP 注入防禦需要結合掃描、監控與執行階段保護工具。

• OWASP ZAP 透過 ZAP Alert 40015 提供 LDAP 注入的主動掃描功能（CWE-90、WASC-29）。可透過 ZAP Marketplace 的 Alpha 掃描規則安裝，並將技術目標設定為包含 Protocol / LDAP，以支援具有 LDAP 整合的應用程式。
• OWASP ModSecurity CRS 提供 WAF 層級的保護，透過 CRS Rule 921200，其預設於 Paranoia Level 1 執行。此規則會檢查 cookies、arguments 與 XML 承載中的 LDAP 篩選器操控特徵。來自 CRS Issue 276 的 CRS 回歸測試承載可提供現成的 fuzzing 字詞清單，用於 WAF 驗證。
• Semgrep 透過 mode: taint 規則支援靜態 taint 分析，可追蹤從 輸入來源 到 LDAP 查詢匯點的不受信任資料，在程式碼進入正式環境前標示注入路徑。
• SIEM 平台 搭配自訂識別規則，可監控 Windows Event IDs 4662 與 1644、關聯異常的 LDAP 查詢模式，並針對如循序屬性列舉或來自非特權主機的大量查詢等行為指標發出警示。

這些工具可處理問題的個別層面。平台化方法則可將它們串聯起來。

Reduce Identity Risk Across Your Organization

Detect and respond to attacks in real-time with holistic solutions for Active Directory and Entra ID.

Get a Demo

相關弱點

有數種弱點類別與 LDAP 注入共享此模式：

• SQL Injection (CWE-89): 最接近的對應類型。兩者都利用查詢語言中未經淨化的輸入，且可透過類似技術達成驗證繞過。語法與目標系統則有顯著差異。
• OS Command Injection (CWE-78): 依據 MITRE，與 CWE-90 共享相同的 Software Fault Pattern (SFP24, "Tainted input to command")。其目標是主機作業系統，而非目錄服務。
• XPath Injection (CWE-643):  OWASP LDAP testing 明確將 XPath 注入與 LDAP 注入歸為類似的驗證繞過技術，目標為以 XML 為基礎的資料儲存。
• Improper Neutralization of Special Elements (CWE-77): 在 MITRE 階層中屬於 CWE-90 的父層弱點。所有注入類型都源自這種未能中和對直譯器具重要意義字元的廣義失敗。
• Improper Encoding or Escaping of Output (CWE-116): 說明了從逸出失敗到注入的直接鏈結。CVE-2021-41232 展示了 CWE-116 → CWE-90 的鏈結，其中 Go 應用程式中的逸出失敗直接導致 LDAP 注入。
• Improper Input Validation (CWE-20): 當應用程式在建構 LDAP 查詢前未驗證輸入格式時，這就是根本原因。

檢視這些相關弱點類型，有助於您將相同的防禦原則套用至整個程式碼庫，而不僅限於 LDAP 特定的程式碼路徑。

相關 CVE

結論

LDAP 注入讓攻擊者能將不受信任的輸入轉變為對您的環境在驗證與存取上所依賴之目錄系統的控制。對您而言，這表示風險很少僅限於單一查詢或單一應用程式。 

如果您以安全方式建構查詢、在正確的情境中跳脫值、限制繫結權限，並密切監控 LDAP 活動，您就能同時降低曝險以及攻擊者橫向移動的空間。