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

LDAP 注入是利用用户引入的参数生成恶意 LDAP 查询，通过构造 LDAP 过滤器来绕过访问控制、用户权限提升。在维持正常过滤器的情况下构造出 AND、OR 操作注入来获得敏感信息。

从2018年1月至2019年1月，CVE中共有4条漏洞信息与其相关。部分漏洞如下：

示例源于 Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php)，源文件名：CWE90_LDAP_Injection__connect_tcp_01.java。

3.1缺陷代码

上述示例代码 39-61 行，程序进行 TCP 连接并读取Socket的数据并赋值给变量 data，在118 行动态构造一个 LDAP 查询语句，119 行对其加以执行。LDAP 为人员组织机构封装了常见的对象类，比如人员（person）含有姓（sn）、名（cn）、电话(telephoneNumber)、密码 (userPassword) 等属性。该查询为了验证是否存在名为变量 data 的员工,但并未对变量 data 的内容做任何过滤。使用最简单的注入方式，令传入参数的值为“*”，则构造的动态查询条件为 “(cn=*)”，这样可以查询到所有员工的信息，导致信息泄露。

使用360代码卫士对上述示例代码进行检测，可以检出“LDAP 注入”缺陷，显示等级为高。从跟踪路径中可以分析出数据的污染源以及数据流向，在代码行第120行报出缺陷，如图1所示：

图1：LDAP 注入的检测示例

3.2 修复代码

在上述修复代码中，第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码值。