突破WAF长度限制的Shiro反序列化实战技巧

最近在渗透测试项目中遇到一个有趣的案例：目标系统存在Shiro框架的反序列化漏洞，但常规自动化工具却因WAF的长度限制全部失效。这种攻防对抗场景在实战中越来越常见——安全设备不断升级检测规则，而攻击者则需要更精细化的绕过技术。本文将分享如何通过手工分析请求特征、调整HTTP方法等技巧，成功突破WAF的字符数限制防御策略。

1. 从自动化失败到手工分析

当发现目标系统使用默认Shiro密钥时，大多数安全工程师的第一反应是启动自动化工具。我也不例外，先后尝试了shiro_attack、ShiroExploit等常见工具，但所有请求都被WAF拦截。有趣的是，工具生成的payload长度存在明显差异：

关键发现出现在对比2100字符和4900字符的请求时：当payload超过约4500字符时必然触发WAF拦截。这暗示着目标WAF可能配置了基于请求体大小的过滤规则。

提示：现代WAF通常组合多种检测机制，单纯长度限制往往配合其他规则共同生效

2. HTTP协议层的绕过尝试

既然长度是硬限制，接下来尝试从协议层面寻找突破口。经典的思路包括：

• 方法混淆：尝试非标准HTTP方法（如GETS、HEADER）
• 参数污染：在URL中重复添加相同参数
• 编码变异：混合使用URL编码、双重编码、大小写变换

其中最有成效的是对HTTP方法的处理。当删除请求行中的方法（保留空行）时，观察到以下现象：

http复制HTTP/1.1 501 Not Implemented
...
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0

虽然服务器返回501错误，但响应中出现了Shiro特有的rememberMe字段。这说明：

1. WAF可能未对非常规HTTP方法实施长度检查
2. Shiro的认证过滤器在Web容器处理前已解析了Cookie

3. 组合技实现稳定绕过

基于以上发现，设计出分阶段攻击方案：

1. 侦察阶段
   使用短payload确认漏洞存在（避免触发WAF）

   bash复制curl -X GETS http://target.com/login -H "Cookie: rememberMe=xxxx(2000字符)"
   

2. 利用阶段
   通过Burp Repeater实施分片攻击：

   • 先发送短请求建立会话
   • 在后续请求中逐步增加长度
   • 关键payload分拆到多个Cookie头

3. 后利用阶段
   使用内存马避免重复触发WAF：

   java复制// 示例：基于Filter的内存马注入
   javax.servlet.Filter.Chain.addFilter(new MaliciousFilter());
   

4. 防御视角的深度解析

从防御方角度看，这种绕过技术之所以有效，源于WAF与Web应用处理逻辑的差异：

1. 处理顺序差异
   Shiro过滤器在WAF检测前处理Cookie，而WAF通常只检查标准HTTP方法

2. 协议解析容错
   许多Web容器对畸形协议有自动修正能力，而WAF可能严格遵循RFC标准

3. 资源消耗权衡
   深度协议分析会显著增加WAF计算开销，导致厂商默认禁用部分检查

建议企业防御时采用分层策略：

• 前端：部署多引擎WAF集群（如ModSecurity+雷池）
• 中间层：在Nginx/IIS上定制Lua脚本检查
• 后端：定期轮换Shiro加密密钥并禁用rememberMe

5. 进阶技巧与实战心得

在实际测试中，还发现几个实用技巧：

• 时间差探测
  被拦截的请求通常立即返回，而合法请求会有业务处理延迟：

  python复制if response.elapsed < 0.1: 
      print("可能触发WAF")
  

• 报错信息利用
  故意构造畸形请求观察错误差异：

  • WAF拦截通常返回标准错误页
  • 真实业务错误会暴露中间件信息

• 会话分割攻击
  将恶意代码分散到多个请求的Session中：

  code复制请求1：Cookie: rememberMe=前半段payload
  请求2：Cookie: rememberMe=后半段payload
  

在一次金融行业测试中，目标系统WAF配置了严格的4000字符限制。最终通过将payload拆分为3个连续的rememberMe字段（每个约1600字符），成功实现了RCE。这种案例印证了安全防护不能仅依赖单一维度检测。