LDAP注入白盒测试

本文目录导读：

什么是LDAP注入？我先用大白话给你捋一捋！
白盒测试第一步：揪出“裸奔”的参数！
白盒测试第二步：构造Payload的艺术！
白盒测试第三步：修复建议，别光顾着秀操作！
今天的测试心得，不吐不快！

天呐！LDAP注入白盒测试居然这么简单？手把手教你避开这个坑！

哎,兄弟们，今天咱们不聊虚的，直接来点硬核干货！我最近在给一个客户的业务系统做安全审计，你猜怎么着？他们的登录接口居然存在LDAP注入漏洞，而且还是一个超级低级的错误——白盒测试一眼就能看出来的那种！当时我差点没把咖啡喷在屏幕上，真的，这种漏洞要是被黑产盯上，整个用户库都得裸奔！所以今天我必须把LDAP注入白盒测试的完整思路掏心窝子分享给你，看完你绝对会有收获！

什么是LDAP注入？我先用大白话给你捋一捋！

LDAP注入，说白了就是攻击者把恶意代码塞进LDAP查询语句里，让服务器执行非预期的操作，就好比你叫外卖，结果有人在订单备注里写了“把门禁密码也送过来”，结果骑手真的照做了——这谁顶得住啊！

很多新手朋友一听到“白盒测试”就头大，觉得肯定得看一大堆代码，烦死了！但其实白盒测试恰恰是最能“开外挂”的方式，因为你能直接看到源码，漏洞就像没穿衣服的皇帝，一眼就能看穿！而且啊，LDAP注入的原理跟SQL注入有点像，但又不太一样，它利用的是LDAP协议的特殊语法，比如(&(uid=admin)(password=xxx))这种，一旦传入的参数没过滤，攻击者就能用、、&这些符号篡改逻辑。

白盒测试第一步：揪出“裸奔”的参数！

拿到代码后,你第一件事干啥？当然是找所有跟LDAP交互的地方啦！比如登录模块、搜索用户功能、修改密码接口……我当时就在客户的一个JSP项目里，发现了这么一行代码：

String filter = "(&(uid=" + username + ")(password=" + password + "))";

妈呀,看到这行代码我直接血压飙升！这哪是写代码，这分明是给攻击者递刀啊！username和password直接从HTTP请求里拿，连个转义都没有，完完全全的“裸奔”状态。白盒测试的第一个精髓就是：千万别放过任何一个拼接字符串的角落！ 你想象一下，如果攻击者在用户名框里输入*)(uid=*))(|(uid=*，那最终的filter就变成了：

(&(uid=*)(uid=*))(|(uid=*)(password=xxx))

这逻辑直接就被绕过了呀！管理员账号岂不是分分钟被拿下？

白盒测试第二步：构造Payload的艺术！

好啦,发现漏洞位置之后，接下来就是考验“想象力”的时候了。LDAP注入的Payload比SQL注入更讲究“逻辑闭合”，因为LDAP查询语句特别依赖括号和操作符的配对，我自己常用的手法是：

*先用`试探**：比如输入*`作为用户名，看能不能返回所有用户，如果页面显示出所有列表，那恭喜你，漏洞被实锤了！
用)(&闭合逻辑：比如admin)(&，这种Payload能破坏原有查询结构，让后面的条件失效。
结合布尔盲注：有时候回显不明显，你可以用(uid=admin)(|(uid=*这种，配合时间延迟或者登录成功/失败的差异来判断。

诶,我记得当时测试那个系统，我用admin加一个后缀，结果服务器直接返回了所有用户的密码哈希值（虽然哈希被脱敏了，但字段名都暴露了），你说吓人不吓人？所以白盒测试的时候，一定要胆大心细，多试几种编码方式，比如URL编码、Unicode编码，很多开发者只过滤了英文半角字符，结果％2a就绕过过滤了！

白盒测试第三步：修复建议，别光顾着秀操作！

发现漏洞如果不能给出靠谱的修复方案,那测试报告就成了一张废纸。LDAP注入的修复思路跟SQL注入类似，核心就是“参数化查询”或者“严格白名单验证”，比如Java里可以用SearchControls配合DirContext的search方法，传入SearchControls参数的时候，其实LDAP本身支持RFC 2254的转义规则，*把、`()\0`这些特殊字符统统转义掉**，就能避免语法注入。

我当时给客户代码加了个简单的工具类：

public static String escapeLDAPSearchFilter(String filter) {
    StringBuilder sb = new StringBuilder();
    for (char c : filter.toCharArray()) {
        if (c == '\\' || c == '(' || c == ')' || c == '*' || c == '/' || c == '\0') {
            sb.append('\\');
        }
        sb.append(c);
    }
    return sb.toString();
}

你看,就这么几行，漏洞洞就给堵上了！但千万别以为这就万无一失了，还是要提醒你在前端JS也做一次校验，双重保险最安心。