[目錄]
0x00 前言
0x01 LDAP出現背景
0x02 LDAP的特性
0x03 LDAP注入攻擊剖析
0x04 防御LDAP注入
0x05 本文小結
0x06 參考資料
前些日子筆者在看OWASP測試指南時看到了對LDAP注入攻擊的介紹，對此產生了興趣，可是上面談論的東西太少，在網上經過一番搜索之后找到了構成本文主要來源的資料，整理出來分享給大家。
本文主要分為兩部分，第一部分為對LDAP的介紹，包括LDAP的應用背景和它的一些特性。第二部分也是本文的重點，講解LDAP的注入攻防，讀者朋友可以看到雖說是攻防，但實際側重注入攻擊層面。第一部分主要整理自IBM Redbooks前三章對LDAP的介紹，第二部分主要來自筆者對08年黑帽大會paper的翻譯。文章結尾會做一個小結，也會舉例說明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正是因此而生。
簡單了解一下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，可以查閱相關資了解這種簡短表示法。
近年來高速發展的信息技術使得組織的數據庫中存儲的數據急劇增加，這些數據很大一部分對于組織、他們的客戶及合作伙伴而言是敏感、不可泄露和至關重要的。
因而，在組織的內部防火墻后通常都安裝有數據庫，同時有入侵機制機制對其進行保護，并且只能由部分應用進行訪問。為了訪問數據庫，用戶必須連接這些應用并向數據庫提交查詢。當這些應用表現不當、沒有過濾用戶輸入就提交查詢時，使用數據庫的風險就會上升。
超過50%的Web應用漏洞都跟輸入驗證有關，這使得代碼注入技術的利用成為可能。這些攻擊近年來如雨后春筍般出現，引發了系統和應用嚴重的安全問題。SQL注入技術是使用和研究得最廣泛的，但除此之外還存在和其他語言或協議相關的注入技術，如Xpath和LDAP。
要防止出現此類攻擊引發的后果，需要研究各種代碼注入的可能性，并將其公之于眾，讓所有的程序員和管理員都知曉。本文將會深入分析LDAP注入技術，因為所有基于LDAP樹的Web應用都可能存在這種攻擊的漏洞。
利用LDAP注入技術的關鍵在于控制用于目錄搜索服務的過濾器。使用這些技術，攻擊者可能直接訪問LDAP目錄樹下的數據庫，及重要的公司信息。情況還可能比這更嚴重，因為許多應用的安全性依賴于基于LDAP目錄的單點登錄環境。
盡管導致這些后果的漏洞易于理解和修復，它們卻一直存在，因為人們對這種攻擊和它們所能造成的后果知之甚少。之前有這種漏洞利用的參考資料，但它們并不適用于大多數形形色色的現代LDAP服務實施方案。本文的主要作用在于對可能利用的新LDAP注入技術做一個展示，并做一個深度分析。
本部分的組織如下：第二和第三節解闡述了LDAP的基礎知識，這些基礎有助于理解在接下來的章節展示中使用的技術。第四節展示了兩種典型的LDAP注入技術，并用案例進行說明示范。第五節用更多地例子說明了盲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
LDAP服務是許多公司和機構日常操作的關鍵組成部分，目錄服務如微軟的Microsoft Active Directory，Novell E-Directory和RedHat Directory服務都基于LDAP協議。不過也有其他的應用和服務會利用LDAP服務。
這些應用和服務通常需要不同的目錄(單獨認證)來工作。例如，一個域需要一個目錄，郵箱和銷售列表也需要一個單獨的目錄，另外遠程訪問、數據庫和其他Web應用都需要目錄。基于LDAP服務的新目錄有多種用途，用于作為用戶認證的集中化信息容器和使能單點登錄環境。這個場景通過減少管理的復雜度、提升安全性和容錯能力而提高了生產力。基本上，基于LDAP服務的應用使用目錄處于如下用途之一：
—訪問控制
—權限管理
—資源管理
由于LDAP服務對于公司網絡的重要性，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注入環境。
這種情況，應用會構造由”&”操作符和用戶引入的的參數組成的正常查詢在LDAP目錄中搜索，例如：
(&(parameter1=value1)(parameter2=value2))
這里Value1和value2是在LDAP目錄中搜索的值，攻擊者可以注入代碼，維持正確的過濾器結構但能使用查詢實現他自己的目標。?
一個登陸頁有兩個文本框用于輸入用戶名和密碼(圖二)。Uname和Pwd是用戶對應的輸入。為了驗證客戶端提供的user/password對，構造如下LDAP過濾器并發送給LDAP服務器：
(&(USER=Uname)(PASSWORD=Pwd))
圖二
如果攻擊者輸入一個有效地用戶名，如r00tgrok，然后再這個名字后面注入恰當的語句，password檢查就會被繞過。
使得Uname=slisberger)(&))，引入任何字符串作為Pwd值，構造如下查詢并發送給服務器：
(&(USER= slisberger)(&)(PASSWORD=Pwd))
LDAP服務器只處理第一個過濾器，即僅查詢(&(USER=slidberger)(&))得到了處理。這個查詢永真，因而攻擊者無需有效地密碼就能獲取對系統的訪問(圖三)。
圖三
現假設下面的查詢會向用戶列舉出所有可見的低安全等級文檔：
(&(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))
則會被忽略。結果就是，所有安全等級的可用文檔都會列舉給攻擊者，盡管他沒有權限查看它們。
圖四 低安全等級的文檔
圖五 所有安全等級的文檔
這種情況，應用會構造由”|”操作符和用戶引入的的參數組成的正常查詢在LDAP目錄中搜索，例如：
(|(parameter1=value1)(parameter2=value2))
這里Value1和value2是在LDAP目錄中搜索的值，攻擊者可以注入代碼，維持正確的過濾器結構但能使用查詢實現他自己的目標。
假設一個資源管理器允許用戶了解系統中可用的資源(打印機、掃描器、存儲系統等)。這便是一個典型的OR注入案例，因為用于展示可用資源的查詢為：
(|(type=Rsc1)(type=Rsc2))
Rsc1和Rsc2表示系統中不同種類的資源，在圖六中，Rsc1=printer，Rsc2=scanner用于列出系統中所以可用的打印機和掃描器。
圖六
如果攻擊者輸入Rsc=printer)(uid=*)，則下面的查詢被發送給服務器：
(|(type=printer)(uid=*))(type=scanner)
LDAP服務器會響應所有的打印機和用戶對象，見圖七
圖七
假設攻擊者可以從服務器響應中推測出什么，盡管應用沒有報出錯信息，LDAP過濾器中注入的代碼卻生成了有效的響應或錯誤。攻擊者可以利用這一行為向服務器問正確的或錯誤的問題。這種攻擊稱之為盲攻擊。LDAP的盲注攻擊比較慢但容易實施，因為它們基于二進制邏輯，能讓攻擊者從lDAP目錄提取信息。
假設一個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的技術訪問所有的信息。
這種情況下，用于推測想要的信息的邏輯與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*))
在本節中，部署了LDAP環境以展示上面說到的注入技術的使用，另外也描述了利用這些漏洞可能造成的影響及這些攻擊對當前系統安全性的重要影響。
在本例中，printerstatus.php頁面接收idprinter參數構造如下的LDAP搜索過濾器：? ? ? ?
(&(idprinter=value1)(objectclass=printer))
LDAP盲注技術可以通過利用Web應用中內建的搜索過濾器首部的AND操作符，獲得LDAP目錄服務的敏感信息。例如，給出圖八中為打印機對象定義的屬性和圖九中找個查詢的響應頁面，這里value1=HPLaserJet2100
圖八
圖九
一個屬性發現攻擊可以使用下面的LDAP注入：
(&(idprinter=HPLaserJet2100)(ipaddresss=*))(objectclass=printer)
(&(idprinter=HPLaserJet2100)(departments=*))(objectclass=printer)
圖十 屬性不存在時的響應
圖十一 屬性存在時的響應
很顯然，攻擊者可以根據返回的結果判斷屬性是否存在。在第一種情況中，應用沒有給出打印機的信息，因為屬性ipaddress并不存在或不可訪問(FALSE)。另一方面，第二種情況中，響應頁面顯示了打印機的狀態，department屬性存在且可以訪問。進一步說，可以使用LDAP注入獲得一些屬性的值。例如，假設攻擊者想獲得department屬性的值：他可以使用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的值。
攻擊者可以使用字符集削減技術減少獲得信息所需的請求數，為完成這一點，他使用通配符測試給定的字符在值中是否為*anywhere*：
(&(idprinter=HPLaserJet2100)(department=*b*))(object=printer))
(&(idprinter=HPLaserJet2100)(department=*n*))(object=printer))
圖十五?department的之中沒有字母”b”
圖十六?department的之中沒有字母”n”
圖十五是測試”b”的響應頁面，沒有結果說明沒有字母”b”，圖十六中響應正常，意味著’n’出現在department值中。
通過這樣處理，構成depaetment值的字母是哪些就可以知道了，一旦字符集削減完成，只有發現的那些字母會用于booleanization處理，因此減少了請求的數量。
前面演示的攻擊都是作用于應用層，因此網絡層的防火墻和入侵檢測機制無法防御這些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注入那么復雜，只要把守好數據的入口和出口就能有效的防御攻擊 ，圖十八是轉義前后對比的例子
文章開始的LDAP介紹到后面LDAP注入與防御部分，讀者朋友可能發現關于LDAP的介紹存在部分內容上的重疊，之所以保留，主要是考慮到這重疊的部分是以不同的視角去看待的。IBM Redbooks的介紹更多多從企業層面出發，而后面的譯文則更多地從一個安全研究者的角度看待問題，內容上差不多，但是體現了個體與整體之間的不同。 再總結一下本文的內容，本文主要分為兩部分，第一部分是對LDAP的介紹，又分為背景介紹和特性的簡單介紹；本文第二部分討論LDAP注入攻擊和防御，攻擊分為普通注入和盲注入，并給出了對應的測試案例。從篇幅上來說，本文重點在LDAP注入這一部分，并不是說防御這一塊不重要，而是因為LDAP雖然類似于數據庫，但是在查詢上相比更為簡單，對于其防御可以參考數據庫的防御措施。另外理解LDAP的特性也很重要，因為部署該服務，除了我們說的注入攻擊之外，服務器管理、配置不當也會引發安全問題。
本文到這里就差不多要結束了，在此再提兩點：LDAP服務開啟的端口是389，如果發現某個服務器上開啟了該端口很可能就是開啟了LDAP服務，針對LDAP的軟件有ldapbroswer、ldap blind explorer；之前說到LDAP注入漏洞在現實生活中真實存在，在這里給出一個LDAP信息泄露的例子，雖然不一定是LDAP注入直接導致的，但足以說明會造成巨大危害，同時也有例可循：
WooYun: 騰訊某研發中心某系統多用戶弱口令可能導致該產品線及業務受影響!
以下是形成本文的過程中參考過較重要的資料：
http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/js/html/wwhelp.htm
http://blog.nci.ca/nciblog/2013/6/12/ldap-injection
http://stackoverflow.com/questions/3028770/preventing-ldap-injection