LDAP注入與防禦剖析

[目錄]

0x00 前言 
0x01 LDAP出現背景 
0x02 LDAP的特性 
0x03 LDAP注入攻擊剖析 
0x04 防禦LDAP注入 
0x05 本文小結 
0x06 參考資料 

0x00 前言

---

前些日子筆者在看OWASP測試指南時看到了對LDAP注入攻擊的介紹，對此產生了興趣，可是上面談論的東西太少，在網上經過一番搜尋之後找到了構成本文主要來源的資料，整理出來分享給大家。

本文主要分為兩部分，第一部分為對LDAP的介紹，包括LDAP的應用背景和它的一些特性。第二部分也是本文的重點，講解LDAP的注入攻防，讀者朋友可以看到雖說是攻防，但實際側重注入攻擊層面。第一部分主要整理自IBM Redbooks前三章對LDAP的介紹，第二部分主要來自筆者對08年黑帽大會paper的翻譯。文章結尾會做一個小結，也會舉例說明LDAP在現實中的真實存在性，最後本文會給出所參考過的資料資訊。

0x01 LDAP出現背景

---

LDAP(Lightweight Directory Access Protocol):輕量級目錄訪問協議，是一種線上目錄訪問協議，主要用於目錄中資源的搜尋和查詢，是X.500的一種簡便的實現。　　　　　 隨著網際網路的廣泛使用，web應用的數量呈爆炸式的增長，而這些應用的資源和資料呈分散式儲存於目錄中。通常不同的應用會有專屬於自己相關資料的目錄，即專有目錄，專有目錄數量的增長導致了資訊孤島(一種不能與其他相關資訊系統之間進行互操作或者說協調工作的資訊系統)的出現，系統和資源的共享及管理變得日益困難。

以查詢聯絡人和加密證照為例，太多的目錄明顯會給計算機搜尋帶來巨大的壓力，當然隨之出現了相應的解決方案，如X.500，不過在介紹X.500之前先討論一下目錄和關係型資料庫之間的一些關係，因為前面提到了web應用的資料是儲存在目錄中，而不是資料庫中。的確，目錄和資料庫有很多共同之處，都能儲存資料、並能在一定程度進行搜尋和查詢。另外還有一種玩笑的說法，使用資料庫存在注入攻擊，怎麼樣才能避免呢?使用LDAP代替資料庫吧，當然這只是玩笑，LDAP的出現可以追溯到1980年，而針對資料庫的SQLI則到2000年左右才出現。

不同之處在於目錄適合於存放靜態資料，而且不同於資料庫，目錄中儲存的資料無論在型別和種類較之資料庫中的資料都要更為繁多，包括音訊、影片、可執行檔案、文字等檔案，另外目錄中還存在目錄的遞迴。相比之下，資料庫中儲存的資料在格式和型別都有較嚴格的約束，資料庫有索引、檢視、能處理事務(通常包含了一個序列的對資料庫的讀/寫操作)。簡單來說資料庫更多見於處理專有型別的資料，而目錄則具有通用用途。目錄中的內容發生變化後會給搜尋操作帶來不便，因而目錄服務在進行最佳化後更適宜於讀訪問，而非寫、修改等操作。

X.500申明瞭目錄客戶端和目錄伺服器使用的目錄訪問協議(DAP)，然而作為應用層協議，DAP要求完整的7層OSI協議棧操作，會要求比小環境(配置、資源有限的環境)所能提供的更多的資源，因此需要一種輕量級的協議來代替X.500，LDAP正是因此而生。

0x02 LDAP特性

---

簡單瞭解一下LDAP：LDAP不定義客戶端和服務端的工作方式，但會定義客戶端和服務端的通訊方式，另外，LDAP還會定義LDAP資料庫的訪問許可權及服務端資料的格式和屬性。LDAP有三種基本的通訊機制：沒有處理的匿名訪問；基本的使用者名稱、密碼形式的認證；使用SASL、SSL的安全認證方式。LDAP和很多其他協議一樣，基於tcp/ip協議通訊，注重服務的可用性、資訊的保密性等等。部署了LDAP的應用不會直接訪問目錄中的內容，一般透過函式呼叫或者API，應用可以透過定義的C、Java的API進行訪問，Java應用的訪問方式為JNDI(Java Naming and Directory Interface)。

LDAP目錄以入口(entry，目錄中儲存的基本資訊單元)的形式儲存和組織資料結構，每個入口有一個唯一標識自己的專屬名稱(distnguished name)，DN由一系列RDNs(ralative distinguished names)組成。另外還有兩個常見的結構，物件類和屬性。物件類(object class)會定義獨一的OID，每個屬性(attribute)也會分配唯一的OID號碼。看一下定義物件類和屬性的例子：

初始物件類定義：

objectclass: top
objectclass: person

詳細物件類定義：

objectclass: person
objectclasses=( 2.5.6.6 NAME 'person' DESC 'Defines entries that generically represent people.' SUP 'top' STRUCTURAL MUST ( cn $ sn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

屬性定義：

attributetypes=( 2.5.4.4 NAME ( 'sn' 'surName' ) DESC 'This is the X.500 surname attribute, which contains the family name of a person.' SUP 2.5.4.41 EQUALITY 2.5.13.2 ORDERING 2.5.13.3 SUBSTR 2.5.13.4 USAGE userApplications )

LDAP以目錄資訊樹形式儲存資訊，包含入口、物件、屬性，關係圖如下：

入口點和屬性之間的關係為：

上述就是筆者對LDAP資料結構的簡單介紹了，LDAP既然主要用於搜尋查詢，那它是怎麼查詢的呢？

search語法：

attribute operator value search filter options:( "&" or "|" (filter1) (filter2) (filter3) ...) ("!" (filter)) 

主要根據屬性和值進行搜尋，就如瀏覽網頁時我們通常並不會直接瀏覽某個目錄，而是其下存在的某個檔案。

LDAP的URL形式為：

ldap://<host>:<port>/<path>
<path>:<dn>[?<artribute>[?<scope>?<filter>]] 

例如： 

ldap://austin.ibm.com/ou=Austin,o=IBM
ldap:///ou=Austin,o=IBM??sub?(cn=Joe Q. Public)

看得出來在URL中這裡使用逗號分隔查詢，而資料庫查詢則使用'&'號，這是LDAP特有的，另外這裡o表示組織(organization)，u表示單元(unit)，cn表示country name，可以查閱相關資瞭解這種簡短表示法。

0x03 LDAP注入攻擊剖析

---

1.引言

近年來高速發展的資訊科技使得組織的資料庫中儲存的資料急劇增加，這些資料很大一部分對於組織、他們的客戶及合作伙伴而言是敏感、不可洩露和至關重要的。

因而，在組織的內部防火牆後通常都安裝有資料庫，同時有入侵機制機制對其進行保護，並且只能由部分應用進行訪問。為了訪問資料庫，使用者必須連線這些應用並向資料庫提交查詢。當這些應用表現不當、沒有過濾使用者輸入就提交查詢時，使用資料庫的風險就會上升。

超過50%的Web應用漏洞都跟輸入驗證有關，這使得程式碼注入技術的利用成為可能。這些攻擊近年來如雨後春筍般出現，引發了系統和應用嚴重的安全問題。SQL隱碼攻擊技術是使用和研究得最廣泛的，但除此之外還存在和其他語言或協議相關的注入技術，如Xpath和LDAP。

要防止出現此類攻擊引發的後果，需要研究各種程式碼注入的可能性，並將其公之於眾，讓所有的程式設計師和管理員都知曉。本文將會深入分析LDAP注入技術，因為所有基於LDAP樹的Web應用都可能存在這種攻擊的漏洞。

利用LDAP注入技術的關鍵在於控制用於目錄搜尋服務的過濾器。使用這些技術，攻擊者可能直接訪問LDAP目錄樹下的資料庫，及重要的公司資訊。情況還可能比這更嚴重，因為許多應用的安全性依賴於基於LDAP目錄的單點登入環境。

儘管導致這些後果的漏洞易於理解和修復，它們卻一直存在，因為人們對這種攻擊和它們所能造成的後果知之甚少。之前有這種漏洞利用的參考資料，但它們並不適用於大多數形形色色的現代LDAP服務實施方案。本文的主要作用在於對可能利用的新LDAP注入技術做一個展示，並做一個深度分析。

本部分的組織如下：第二和第三節解闡述了LDAP的基礎知識，這些基礎有助於理解在接下來的章節展示中使用的技術。第四節展示了兩種典型的LDAP注入技術，並用案例進行說明示範。第五節用更多地例子說明了盲LDAP注入是如何完成的。最後，第六節是一些對抗這些攻擊的安全建議。

2. LDAP概覽

輕量級目錄訪問協議是透過TCP/IP查詢和修改目錄服務的協議，使用最廣泛的LDAP服務如微軟的ADAM(Active Directory Application Mode)和OpenLDAP。

LDAP目錄服務是用於共享某些通用屬性的儲存和組織資訊的軟體應用程式,資訊基於目錄樹入口被結構化，而伺服器提供方便的瀏覽和搜尋等服務。LDAP是物件導向的，因此LDAP目錄服務中的每一個入口都是一個物件例項，並且必須對應該物件屬性的規則。

由於LDAP目錄服務的層次化的性質，基於讀取的查詢得到了最佳化，而寫查詢則受到抑制。

LDAP同樣基於客戶端/伺服器模型，最常見的操作時使用過濾器搜尋目錄入口。客戶端向伺服器傳送查詢，伺服器則響應匹配這些過濾器的目錄入口。

LDAP過濾器定義於RFC4515中，這些過濾器的結構可概括如下：

Fileter = (filtercomp)
Filtercomp = and / or / not / item
And = & filterlist
Or = | filterlist
Not = ! filter
Filterlist = 1*filter
Item = simple / present / substring
Simple = “=” / “~=” / ”>=” / “<=”
Present = attr =*
Substring = attr “=” [initial]*[final]
Initial = assertion value
Final = assertion value

所有過濾器必須置於括號中，只有簡化的邏輯運算子(AND、OR、NOT)和關係運算子(=、>=、<=、~=)可用於構造它們。特殊符“*”可用來替換過濾器中的一個或多個字元。

除使用邏輯運算子外，RFC4256還允許使用下面的單獨符號作為兩個特殊常量：

(&)     ->Absolute TRUE 
(|)     ->Absolute FALSE 

3. 常見的LDAP環境

LDAP服務是許多公司和機構日常操作的關鍵組成部分，目錄服務如微軟的Microsoft Active Directory，Novell E-Directory和RedHat Directory服務都基於LDAP協議。不過也有其他的應用和服務會利用LDAP服務。

這些應用和服務通常需要不同的目錄(單獨認證)來工作。例如，一個域需要一個目錄，郵箱和銷售列表也需要一個單獨的目錄，另外遠端訪問、資料庫和其他Web應用都需要目錄。基於LDAP服務的新目錄有多種用途，用於作為使用者認證的集中化資訊容器和使能單點登入環境。這個場景透過減少管理的複雜度、提升安全性和容錯能力而提高了生產力。基本上，基於LDAP服務的應用使用目錄處於如下用途之一：

—訪問控制 
—許可權管理 
—資源管理 

由於LDAP服務對於公司網路的重要性，LDAP伺服器通常和其他資料庫伺服器一起放置於後端。圖一展示了部署公司網路的典型場景，記住這個場景對於理解後面展示的注入技術的含義是很有用的。

圖一

4. Web應用中的LDAP注入

LDAP注入攻擊和SQL隱碼攻擊相似，因此接下來的想法是利用使用者引入的引數生成LDAP查詢。一個安全的Web應用在構造和將查詢傳送給伺服器前應該淨化使用者傳入的引數。在有漏洞的環境中，這些引數沒有得到合適的過濾，因而攻擊者可以注入任意惡意程式碼。

記住第二節中說道的LDAP過濾器的結構和使用得最廣泛的LDAP：ADAM和OpenLDAP，下面的結論將會致程式碼注入：

(attribute=value):如果過濾器用於構造查詢單缺少邏輯運算子，如value)(injected_filter的注入會導致兩個過濾器(attribute=value)(injected\_filter)。在OpenLDAP實施中，第二個過濾器會被忽略，只有第一個會被執行。而在ADAM中，有兩個過濾器的查詢是不被允許的，因而這個注入毫無用處。

(|(attribute=value)(second_filter)) or (&(attribute=value)(second_filter)):如果第一個用於構造查詢的過濾器有邏輯運算子，形如value)(injected_filter)的注入會變成如下過濾器：(&(attribute=value)(injected_filter)) (second_filter)。雖然過濾器語法上並不正確，OpenLDAP還是會從左到右進行處理，忽略第一個過濾器閉合後的任何字元。一些LDAP客戶端Web組成會忽略第二個過濾器，將ADAM和OpenLDAP傳送給第一個完成的過濾器，因而存在注入。

一些應用框架在將請求傳送給伺服器之前會檢查過濾器是否正確，在這種情況下，過濾器語義上必須是正確的，其注入如：value)(injected_filter))(&(1=0。這會導致出現兩個不同的過濾器，第二個會被忽略：(&(attribute=value)(injected_filter))(&(1=0)(second_filter))。

既然第二個過濾器會被LDAP伺服器忽略，有些部分便不允許有兩個過濾器的查詢。這種情況下，只能構建一個特殊的注入以獲得單個過濾器的LDAP查詢。value)(injected_filter這樣的注入產生的結果是：(&(attribute=value)(injected_filter)(second_filter))。

測試一個應用是否存在程式碼注入漏洞典型的方法是向伺服器傳送會生成一個無效輸入的請求。因此，如果伺服器返回一個錯誤訊息，攻擊者就能知道伺服器執行了他的查詢，他可以利用程式碼注入技術。回想一下之前討論的，我們可以將注入環境分為兩種：AND注入環境和OR注入環境。

4.1 AND注入

這種情況，應用會構造由”&”運算子和使用者引入的的引數組成的正常查詢在LDAP目錄中搜尋，例如：

(&(parameter1=value1)(parameter2=value2))

這裡Value1和value2是在LDAP目錄中搜尋的值，攻擊者可以注入程式碼，維持正確的過濾器結構但能使用查詢實現他自己的目標。 

4.1.1 案例1：繞過訪問控制

一個登陸頁有兩個文字框用於輸入使用者名稱和密碼(圖二)。Uname和Pwd是使用者對應的輸入。為了驗證客戶端提供的user/password對，構造如下LDAP過濾器併傳送給LDAP伺服器：

(&(USER=Uname)(PASSWORD=Pwd)) 

圖二

如果攻擊者輸入一個有效地使用者名稱，如r00tgrok，然後再這個名字後面注入恰當的語句，password檢查就會被繞過。

使得Uname=slisberger)(&))，引入任何字串作為Pwd值，構造如下查詢併傳送給伺服器：

(&(USER= slisberger)(&)(PASSWORD=Pwd))

LDAP伺服器只處理第一個過濾器，即僅查詢(&(USER=slidberger)(&))得到了處理。這個查詢永真，因而攻擊者無需有效地密碼就能獲取對系統的訪問(圖三)。

圖三

4.1.2 案例二：許可權提升

現假設下面的查詢會向使用者列舉出所有可見的低安全等級文件：

(&(directory=document)(security_level=low)) 

這裡第一個引數document是使用者入口，low是第二個引數的值。如果攻擊者想列舉出所有可見的高安全等級的文件，他可以利用如下的注入：

document)(security_level=*))(&(directory=documents

生成的過濾器為：

(&(directory=documents)(security_level=*))(&(direcroty=documents)(security_level=low))

LDAP伺服器僅會處理第一個過濾器而忽略第二個，因而只有下面的查詢會被處理：

(&(directory=documents)(security_level=*))

而

(&(direcroty=documents)(security_level=low))

則會被忽略。結果就是，所有安全等級的可用文件都會列舉給攻擊者，儘管他沒有許可權檢視它們。

圖四 低安全等級的文件

圖五 所有安全等級的文件

4.2 OR注入

這種情況，應用會構造由”|”運算子和使用者引入的的引數組成的正常查詢在LDAP目錄中搜尋，例如：

(|(parameter1=value1)(parameter2=value2))

這裡Value1和value2是在LDAP目錄中搜尋的值，攻擊者可以注入程式碼，維持正確的過濾器結構但能使用查詢實現他自己的目標。

4.2.1 案例1：資訊洩露

假設一個資源管理器允許使用者瞭解系統中可用的資源(印表機、掃描器、儲存系統等)。這便是一個典型的OR注入案例，因為用於展示可用資源的查詢為：

(|(type=Rsc1)(type=Rsc2))

Rsc1和Rsc2表示系統中不同種類的資源，在圖六中，Rsc1=printer，Rsc2=scanner用於列出系統中所以可用的印表機和掃描器。

圖六

如果攻擊者輸入Rsc=printer)(uid=*)，則下面的查詢被髮送給伺服器：

(|(type=printer)(uid=*))(type=scanner)

LDAP伺服器會響應所有的印表機和使用者物件，見圖七

圖七

5. LDAP盲注入

假設攻擊者可以從伺服器響應中推測出什麼，儘管應用沒有報出錯資訊，LDAP過濾器中注入的程式碼卻生成了有效的響應或錯誤。攻擊者可以利用這一行為向伺服器問正確的或錯誤的問題。這種攻擊稱之為盲攻擊。LDAP的盲注攻擊比較慢但容易實施，因為它們基於二進位制邏輯，能讓攻擊者從lDAP目錄提取資訊。

5.1 AND盲注

假設一個Web應用想從一個LDAP目錄列出所有可用的Epson印表機，錯誤資訊不會返回，應用傳送如下的過濾器：         

(&(objectClass=printer)(type=Epson*))

使用這個查詢，如果有可用的Epson印表機，其圖示就會顯示給客戶端，否則沒有圖示出現。如果攻擊者進行LDAP盲注入攻擊

*)(objectClass=*))(&(objectClass=void

Web應用會構造如下查詢：      

(&(objectClass=*)(objectClass=*))(&(objectClass=void)(type=Epson*))

僅第一個LDAP過濾器會被處理：

(&(objectClass=*)(objectClass=*))

結果是，印表機的圖示一定會顯示到客戶端，因為這個查詢總是會獲得結果：過濾器objectClass=*總是返回一個物件。當圖示被顯示時響應為真，否則為假。

從這一點來看，使用盲注技術比較容易，例如構造如下的注入：         

(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(type=Epson*))
(&(objectClass=*)(objectClass=resources))(&(objectClass=foo)(type=Epson*))

這種程式碼注入的設定允許攻擊者推測可能存在於LDAP目錄服務中不同物件類的值。當響應Web頁面至少包含一個印表機圖示時，物件類的值就是存在的，另一方面而言，如果物件類的值不存在或沒有對它的訪問，就不會有圖示出現。

LDAP盲注技術讓攻擊者使用基於TRUE/FALSE的技術訪問所有的資訊。

5.2 OR盲注

這種情況下，用於推測想要的資訊的邏輯與AND是相反的，因為使用的是OR邏輯運算子。接下來使用的是同一個例子，OR環境的注入為：

(|(objectClass=void)(objectClass=void))(&(objectClass=void)(type=Epson*))

這個LDAP查詢沒有從LDAP目錄服務獲得任何物件，印表機的圖示也不會顯示給客戶端(FALSE)。如果在響應的Web頁面中有任何圖示，則響應為TRUE。故攻擊者可以注入下列LDAP過濾器來收集資訊：      

(|(objectClass=void)(objectClass=users))(&(objectClass=void)(type=Epson*))
(|(objectClass=void)(objectClass=resources))(&(objectClass=void)(type=Epson*))

5.3 利用案例

在本節中，部署了LDAP環境以展示上面說到的注入技術的使用，另外也描述了利用這些漏洞可能造成的影響及這些攻擊對當前系統安全性的重要影響。

在本例中，printerstatus.php頁面接收idprinter引數構造如下的LDAP搜尋過濾器：       

(&(idprinter=value1)(objectclass=printer))

5.3.1 發現屬性

LDAP盲注技術可以透過利用Web應用中內建的搜尋過濾器首部的AND運算子，獲得LDAP目錄服務的敏感資訊。例如，給出圖八中為印表機物件定義的屬性和圖九中找個查詢的響應頁面，這裡value1=HPLaserJet2100

圖八

圖九

一個屬性發現攻擊可以使用下面的LDAP注入：

(&(idprinter=HPLaserJet2100)(ipaddresss=*))(objectclass=printer)
(&(idprinter=HPLaserJet2100)(departments=*))(objectclass=printer)

圖十 屬性不存在時的響應

圖十一 屬性存在時的響應

很顯然，攻擊者可以根據返回的結果判斷屬性是否存在。在第一種情況中，應用沒有給出印表機的資訊，因為屬性ipaddress並不存在或不可訪問(FALSE)。另一方面，第二種情況中，響應頁面顯示了印表機的狀態，department屬性存在且可以訪問。進一步說，可以使用LDAP注入獲得一些屬性的值。例如，假設攻擊者想獲得department屬性的值：他可以使用booleanization和字符集削減技術，這將在下一節中介紹。

5.3.2 Booleanization

攻擊者可以使用字母、數字搜尋提取屬性的值，這個想法的關鍵在於將一個複雜的值轉化為TRUE/FALSE列表。這個機制，通常稱為booleanization，大意是二值化吧，圖十二概括了該機制，可用於不同的方式。

假設攻擊者想知道department屬性的值，處理如下：

(&(idprinter=HPLaserJet2100)(department=a*))(object=printer))
(&(idprinter=HPLaserJet2100)(department=f*))(object=printer))
(&(idprinter=HPLaserJet2100)(department=fa*))(object=printer))

圖十三 值不是以’a’開始

圖十四 值以’fi’開始

如圖九所示，本例中department的值是financial，用”a”的嘗試沒有獲取任何印表機資訊，因而第一個字母不是”a”。測試過其他字母后，唯一能正常返回的只有”f”，接下來測試第二個字母，當為”i”時才正常返回，如圖十四，以此類推即可獲得department的值。

5.3.3 字符集削減

攻擊者可以使用字符集削減技術減少獲得資訊所需的請求數，為完成這一點，他使用萬用字元測試給定的字元在值中是否為*anywhere*：

(&(idprinter=HPLaserJet2100)(department=*b*))(object=printer))
(&(idprinter=HPLaserJet2100)(department=*n*))(object=printer))

圖十五 department的之中沒有字母”b”

圖十六 department的之中沒有字母”n”

圖十五是測試”b”的響應頁面，沒有結果說明沒有字母”b”，圖十六中響應正常，意味著’n’出現在department值中。

透過這樣處理，構成depaetment值的字母是哪些就可以知道了，一旦字符集削減完成，只有發現的那些字母會用於booleanization處理，因此減少了請求的數量。

0x04 防禦LDAP注入

---

前面演示的攻擊都是作用於應用層，因此網路層的防火牆和入侵檢測機制無法防禦這些LDAP注入攻擊。然而遵循最小化暴露點和最小化許可權的原則可以減小或最小化其影響。

用於防禦程式碼注入技術的機制包括防禦性程式設計、複雜的輸入驗證、動態檢查和原始碼分析，減輕LDAP注入的工作必須涉及相似的技術。

之前的LDAP注入攻擊演示都在從客戶端傳送給伺服器的引數中包含了特殊字元，因而有必要在傳送查詢給伺服器之前對變數進行檢查和淨化處理。

總而言之，我們看到圓括號、星號、邏輯運算子、關係運運算子在應用層都必須過濾。

無論什麼時候，只要可能，構造LDAP搜尋過濾器的值在傳送給LDAP伺服器查詢之前都要用應用層有效地值列表來核對。

圖十七包含了LDAP中用到的特殊字元和需要轉義處理的字元：

左邊的字元在正常情況下是不會用到的，如果在使用者的輸入中出現了需要用反斜槓轉義處理。而右邊的圓括號這些如果不過濾的話就會導致過濾器閉合而生產攻擊者需要的filter，這裡看到不僅是用反斜槓處理，還將字元變成了相應的ASCII碼值，這些符號本不該出現。

圖十七

上面這些字元的處理在RFC2254中都能找到，具體實現可參考如下一段PHP程式碼：

#!php
function ldapspecialchars($string) {
    $sanitized=array('\\' => '\5c',
                     '*' => '\2a',
                     '(' => '\28',
                     ')' => '\29',
                     "\x00" => '\00');

    return str_replace(array_keys($sanitized),array_values($sanitized),$string);
}

對LDAP服務而言防禦注入並不像SQL隱碼攻擊那麼複雜，只要把守好資料的入口和出口就能有效的防禦攻擊 ，圖十八是轉義前後對比的例子

0x05 本文小結

---

文章開始的LDAP介紹到後面LDAP注入與防禦部分，讀者朋友可能發現關於LDAP的介紹存在部分內容上的重疊，之所以保留，主要是考慮到這重疊的部分是以不同的視角去看待的。IBM Redbooks的介紹更多多從企業層面出發，而後面的譯文則更多地從一個安全研究者的角度看待問題，內容上差不多，但是體現了個體與整體之間的不同。 再總結一下本文的內容，本文主要分為兩部分，第一部分是對LDAP的介紹，又分為背景介紹和特性的簡單介紹；本文第二部分討論LDAP注入攻擊和防禦，攻擊分為普通注入和盲注入，並給出了對應的測試案例。從篇幅上來說，本文重點在LDAP注入這一部分，並不是說防禦這一塊不重要，而是因為LDAP雖然類似於資料庫，但是在查詢上相比更為簡單，對於其防禦可以參考資料庫的防禦措施。另外理解LDAP的特性也很重要，因為部署該服務，除了我們說的注入攻擊之外，伺服器管理、配置不當也會引發安全問題。

0x06 參考資料

---

本文到這裡就差不多要結束了，在此再提兩點：LDAP服務開啟的埠是389，如果發現某個伺服器上開啟了該埠很可能就是開啟了LDAP服務，針對LDAP的軟體有ldapbroswer、ldap blind explorer；之前說到LDAP注入漏洞在現實生活中真實存在，在這裡給出一個LDAP資訊洩露的例子，雖然不一定是LDAP注入直接導致的，但足以說明會造成巨大危害，同時也有例可循：

WooYun: 騰訊某服務配置不當內部海量敏感資訊洩露!

WooYun: 騰訊某研發中心某系統多使用者弱口令可能導致該產品線及業務受影響!

以下是形成本文的過程中參考過較重要的資料：

http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/js/html/wwhelp.htm

https://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/bh-eu-08-alonso-parada-WP.pdf

http://blog.nci.ca/nciblog/2013/6/12/ldap-injection

http://stackoverflow.com/questions/3028770/preventing-ldap-injection