您好,登錄后才能下訂單哦!
這篇文章的內容主要圍繞LDAP注入該如何理解進行講述,文章內容清晰易懂,條理清晰,非常適合新手學習,值得大家去閱讀。感興趣的朋友可以跟隨小編一起閱讀吧。希望大家通過這篇文章有所收獲!
LDAP (Light Directory Access Portocol) 是基于X.500標準的輕量級目錄訪問協議,提供訪問目錄數據庫方法的服務和協議,常用于與目錄數據庫組成目錄服務。其中目錄是一個為查詢、瀏覽和搜索而優化的專業分布式數據庫,它呈樹狀結構組織數據,類似于Linux/Unix系統中的文件目錄。公用證書、安全密鑰、公司的物理設備信息等修改并不頻繁的數據適合存儲在目錄中。可以將LDAP理解為一種搜索協議,它類似于SQL,擁有查詢語法,也存在被注入攻擊的風險。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注入該如何理解”這一問題有一定的了解,快去動手實踐吧,如果想了解更多相關知識點,可以關注億速云網站!小編會繼續為大家帶來更好的文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。