LDAP (Light Directory Access Portocol) 是基於X.500標準的輕量級目錄存取協議，提供存取目錄資料庫方法的服務和協議，常用於與目錄資料庫組成目錄服務。其中目錄是一個為查詢、瀏覽和搜尋而優化的專業分散式資料庫，它呈現樹狀結構組織數據，類似於Linux/Unix系統中的檔案目錄。適合將公用憑證、安全金鑰以及公司實體設備資訊等不經常變更的資料儲存於目錄中。類似於SQL，LDAP是一種搜尋協議，具有查詢語法，並存在潛在的注入攻擊風險。 LDAP注入是指客戶端發送查詢請求時，輸入的字串中含有一些特殊字符，導致修改了LDAP本來的查詢結構，從而使得可以存取更多的未授權資料的一種攻擊方式。
本篇文章以 JAVA 語言原始碼為例，分析CWE ID 90：Improper Neutralization of Special Elementsused in an LDAP Query ('LDAP Injection')樣本中LDAP注入漏洞產生的原因以及修復方法。詳細請參閱：
CWE ID 90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
#http://cwe .mitre.org/data/definitions/90.html
CWE ID 639：Authorization Bypass ThroughUser-Controlled Key
#http://cwe.mitre.org/ data/definitions/639.html
2. LDAP 注入的危害
LDAP 注入是利用使用者引入的參數產生惡意LDAP 查詢，透過建構LDAP 過濾器來繞過存取控制、使用者權限提升。透過針對正常過濾器的構造，實現 AND、OR 操作注入，以獲取敏感資訊。
從2018年1月至2019年1月，CVE中共有4個漏洞資訊與其相關。部分漏洞如下：
| #CVE 編號 | |
|---|---|
| CVE-2018-12689 | phpLDAPadmin 1.2.2 允許通過cmd.php？ cmd = loginform 請求中精心設計的 serverid 參數或登入面板中精心設計的使用者名稱和密碼進行 LDAP 注入。 |
| CVE-2018-5730 | MIT krb5 1.6 或更高版本允許經過驗證的kadmin 將主體新增至LDAP Kerberos 資料庫，以透過提供「linkdn”和「containerdn」 資料庫參數來繞過DN容器檢查，或透過提供作為擴展的DN字串來繞過DN 容器檢查。 |
| CVE-2016-8750 | 4.0.8 之前的 Apache Karaf 使用 LDAPLoginModule 透過 LDAP 對使用者進行驗證。但是沒有正確編碼使用者名，因此容易受到 LDAP 注入攻擊，導致拒絕服務。 |
| CVE-2011-4069 | PacketFence 3.0.2 之前的html / admin / login.php 允許遠端攻擊者進行LDAP 注入攻擊，從而透過精心設計的使用者名稱繞過身份驗證。 |
範例源自於Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php)，來源檔案名稱：CWE90_LDAP_Injection__connect_tcp_01.java。
#上述範例程式碼39-61 行，程式進行TCP 連接並讀取Socket的資料並賦值給變數data，在118 行動態建構一個LDAP 查詢語句，119 行對其執行。 LDAP 為人員組織機構封裝了常見的物件類，例如人員（person）含有姓氏（sn）、名稱（cn）、電話(telephoneNumber)、密碼 (userPassword) 等屬性。該查詢為了驗證是否存在名為變數 data 的員工,但並未對變數 data 的內容做任何過濾。使用最簡單的注入方式，令傳入參數的值為“*”，則建構的動態查詢條件為 "(cn=*)”，這樣可以查詢到所有員工的信息，導致資訊外洩。
對上文中的範例程式碼進行360程式碼衛士偵測後，發現有「LDAP注入」漏洞，安全等級評定為高。資料污染源以及資料流向可以透過追蹤路徑分析得出並在程式碼的第120行報告缺陷，圖1亦如是
圖1：LDAP 注入的偵測範例
在上述修復程式碼中，第119行使用javax. naming.ldap 套件下擴充類別BaseControl 接收需要被處理的參數，第120行control 物件呼叫getEncodedValue() 方法將接收的參數data 進行編碼，編碼後的值為字元對應的ASN.1BER 編碼值。編碼後的位元組數組不存在參與指令解析的特殊字符，可以建構結構、內容正常的 LDAP 查詢語句，這樣就避免了 LDAP 注入的發生。
使用360程式碼衛兵對修復後的程式碼進行偵測，可以看到已不存在「LDAP注入」缺陷。如圖2：
圖2：修正後偵測結果
LDAP注入的根本原因是攻擊者利用LDAP元字元來修改LDAP查詢的意義。在建構LDAP篩選器時，程式設計師需明確哪些字元該被視為指令解析，哪些字元應被視為資料解析。為了防止攻擊者侵犯程式設計師的各種預設情況，應使用白名單的方法，確保LDAP查詢中由使用者控制的數值完全來自於預定的字元集合，應不包含任何LDAP元字元。如果由使用者控制的數值範圍要求必須包含 LDAP元字符，則應使用相應的編碼機制轉義這些元字符在LDAP查詢中的意義。
#
如&、！ 、|、=、、，、 、-、」、'、；這些字元正常情況下不會用到，如果使用者的輸入中出現了，需要用反斜線轉義處理。
還有一些字元如(、)、\、*、/、NUL這些字元不僅需要用反斜線處理，還要將字元變成對應的ASCII碼值。
以上是LDAP注入該如何理解的詳細內容。更多資訊請關注PHP中文網其他相關文章！
