HttpRequestWrapper如何安全过滤恶意参数？

Question

在使用 `HttpRequestWrapper` 进行请求参数过滤时，如何在不破坏原始请求流的前提下，安全地拦截并过滤 XSS 或 SQL 注入等恶意参数？常见问题包括：多次读取 `InputStream` 导致 body 数据丢失、包装类未正确重写 `getParameter` 系列方法导致绕过过滤、以及字符编码处理不当引发的漏判。如何通过重写 `HttpServletRequestWrapper` 实现参数的透明过滤，同时保证请求体可重复读取，并兼顾性能与安全性？

Answer 1

一、背景与核心挑战

在现代Web应用安全体系中，HttpServletRequestWrapper 被广泛用于对HTTP请求参数进行透明过滤，以防御XSS（跨站脚本）和SQL注入等常见攻击。然而，在实际开发过程中，开发者常面临三大典型问题：

• 多次读取 InputStream 导致 body 数据丢失：原始请求体只能被消费一次，后续调用 getInputStream() 或 getReader() 将返回空流。
• 包装类未重写 getParameter 系列方法：若仅拦截部分参数获取方式，攻击者可通过表单提交、JSON body 或 multipart 请求绕过过滤逻辑。
• 字符编码处理不当引发漏判：未统一解码标准可能导致恶意负载因编码差异而逃逸检测规则。

这些问题直接影响了过滤机制的完整性与可靠性，因此需要构建一个可重复读取、全面覆盖参数入口、并支持安全编码处理的请求包装方案。

二、技术实现路径分析

为解决上述问题，需从以下四个维度设计解决方案：

1. 缓存原始请求体内容，确保流可重复读取；
2. 完整重写 getParameter, getParameterMap, getParameterValues 等方法；
3. 统一字符集解析逻辑，防止编码混淆攻击；
4. 集成轻量级安全过滤器，如使用 OWASP Java Encoder 或自定义正则策略。

三、关键实现：可重复读取的 Request Wrapper

通过继承 HttpServletRequestWrapper 并封装原始输入流为可回溯的缓存流，是实现透明过滤的基础。以下是核心代码结构：

public class XssSqlRequestWrapper extends HttpServletRequestWrapper {
    private final byte[] cachedBody;

    public XssSqlRequestWrapper(HttpServletRequest request) throws IOException {
        super(request);
        // 缓存请求体
        InputStream inputStream = request.getInputStream();
        this.cachedBody = StreamUtils.copyToByteArray(inputStream);
    }

    @Override
    public ServletInputStream getInputStream() {
        return new CachedServletInputStream(this.cachedBody);
    }

    @Override
    public BufferedReader getReader() {
        ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(this.cachedBody);
        return new BufferedReader(new InputStreamReader(byteArrayInputStream, getCharacterEncoding()));
    }

    // 重写 getParameter 系列方法
    @Override
    public String getParameter(String name) {
        String value = super.getParameter(name);
        return sanitizeValue(value);
    }

    @Override
    public String[] getParameterValues(String name) {
        String[] values = super.getParameterValues(name);
        if (values == null) return null;
        return Arrays.stream(values).map(this::sanitizeValue).toArray(String[]::new);
    }

    @Override
    public Map<String, String[]> getParameterMap() {
        Map<String, String[]> parameterMap = new LinkedHashMap<>(super.getParameterMap());
        Map<String, String[]> sanitizedMap = new LinkedHashMap<>();
        parameterMap.forEach((key, value) ->
            sanitizedMap.put(key, Arrays.stream(value).map(this::sanitizeValue).toArray(String[]::new))
        );
        return Collections.unmodifiableMap(sanitizedMap);
    }

    private String sanitizeValue(String value) {
        if (value == null) return null;
        // 示例：基础XSS过滤
        value = value.replaceAll("<script.*?>.*?</script>", "");
        // SQL注入关键词过滤（生产环境建议使用预编译）
        value = value.replaceAll("(?i)(union\\s+select|drop\\s+table|insert\\s+into)", "");
        return value.trim();
    }
}
    

四、缓存流实现：CachedServletInputStream

为支持多次读取，必须自定义 ServletInputStream 子类：

private static class CachedServletInputStream extends ServletInputStream {
    private final ByteArrayInputStream bais;

    public CachedServletInputStream(byte[] cachedBody) {
        this.bais = new ByteArrayInputStream(cachedBody);
    }

    @Override
    public boolean isFinished() { return this.bais.available() == 0; }
    @Override
    public boolean isReady() { return true; }
    @Override
    public int available() { return this.bais.available(); }
    @Override
    public int read() { return this.bais.read(); }
    @Override
    public void close() { this.bais.close(); }
}
    

五、过滤策略优化与性能考量

直接在 wrapper 中执行复杂正则或HTML解析会影响性能。推荐采用如下优化策略：

策略	说明	适用场景
延迟过滤	仅在调用 getParameter 时触发清洗	低频参数访问
预加载过滤	构造时即完成所有参数净化	高频调用接口
白名单机制	基于字段类型选择不同规则（如用户名仅允许字母数字）	高安全性要求系统
异步日志审计	记录可疑参数用于后续分析	合规性需求

六、编码一致性处理

为避免因编码不一致导致的漏判，应在读取参数前统一使用请求指定的字符集：

String encoding = request.getCharacterEncoding();
if (encoding == null) encoding = "UTF-8"; // 默认编码兜底
InputStreamReader isr = new InputStreamReader(inputStream, encoding);
    

同时建议在前端与网关层强制设置 Content-Type: application/x-www-form-urlencoded; charset=UTF-8，形成端到端编码规范。

七、部署流程图：Filter 驱动的请求过滤链

graph TD
            A[客户端发起请求] --> B{Filter 判断是否需要包装}
            B -- 是 --> C[创建 XssSqlRequestWrapper]
            C --> D[缓存 InputStream 到内存]
            D --> E[注册包装后 request]
            E --> F[Controller 接收请求]
            F --> G[调用 getParameter 获取参数]
            G --> H[XssSqlRequestWrapper 执行 sanitizeValue]
            H --> I[返回净化后参数]
            I --> J[业务逻辑处理]
            J --> K[响应返回客户端]
            B -- 否 --> F

八、边界情况与防御绕过风险

尽管已包装请求，仍需警惕以下绕过手段：

• JSON Body 攻击：Spring MVC 中 @RequestBody 不走 getParameter 流程，需结合 HandlerInterceptor 或 AOP 进行额外校验。
• Multipart 文件名注入：文件上传中的 filename 可能携带脚本，应单独校验 Header。
• 嵌套对象遍历缺失：复杂对象绑定时需递归清理每个字段。
• 编码混淆测试：尝试 %3Cscript%3E、<script> 等变体，验证过滤器鲁棒性。

九、生产环境最佳实践建议

综合安全性与性能，推荐以下配置组合：

1. 使用 OncePerRequestFilter 确保包装唯一性；
2. 限制缓存 body 大小（如 ≤ 1MB），防内存溢出；
3. 结合 WAF 层做前置过滤，降低应用层压力；
4. 启用参数白名单机制，非必要字段拒绝传递；
5. 定期更新 XSS/SQLi 规则库，集成如 OWASP AntiSamy；
6. 对敏感操作添加二次确认或 Token 校验；
7. 开启访问日志脱敏，防止日志注入；
8. 使用 Content Security Policy (CSP) 减少 XSS 影响面；
9. 对 API 接口实施 Schema 校验（如 JSON Schema）；
10. 建立自动化渗透测试 pipeline，持续验证防护有效性。