核心是构建有逻辑、可验证、能反馈的闭环流程：先精准定位URL参数、请求体、HTTP头、路径片段四类入口点，再分三级构造有效载荷，最后通过状态码、响应长度、字符串缺失、DOM解析等多维差异判定过滤失效并定位缺陷环节。
实施针对 Web 应用入口点参数过滤机制的自动化漏洞测试，核心不是“跑工具”，而是构建一个有逻辑、可验证、能反馈的闭环流程：先精准定位所有可能被过滤器处理的输入位置，再用有针对性的畸形数据触发过滤行为，最后通过响应差异确认过滤是否失效或可绕过。
一、全面识别待测入口点
过滤机制覆盖范围远不止 URL 参数。必须系统梳理四类高频入口：
-
URL 查询参数：如
/user?id=123&type=profile中的id和type -
POST/PUT 请求体：JSON、表单（
application/x-www-form-urlencoded）、XML 等格式中的字段值 -
HTTP 请求头：特别是
User-Agent、Referer、X-Forwarded-For、Cookie，常被忽略但极易反射或参与日志记录 -
路径片段与文件名：如
/api/v1/users/{id}中的{id}，或上传接口中可控的文件名字段
建议使用 Burp Suite 的 Target → Site map + Engagement tools → Discover content，辅以手动爬取和 API 文档比对，避免遗漏动态生成的端点。
二、构造分层有效载荷集
单一 payload 很难击穿现代过滤器。应按“绕过强度”分三级准备：
-
基础探测型：用于快速判断是否做过滤，例如
' " <script></script>、1' OR '1'='1、 -
编码混淆型：绕过简单关键字匹配，如
%27%20UNION%20SELECT%201,2,3--、<script>alert(1)</script>、javascript:alert(1) -
上下文适配型：根据反射位置调整语法，比如在属性值中用
" onfocus=alert(1) x="，在 JS 字符串中用\x27+alert(1)+\x27，在 HTML 注释后用--><script>alert(1)</script>
可直接导入 OWASP XSS Filter Evasion Cheat Sheet 或 SQLi Filter Evasion List 到 Burp Intruder 或 ffuf，避免重复造轮子。
三、设计差异化响应判定策略
过滤器是否起效，不能只看“报错”或“弹窗”。需多维度比对响应特征：
- 状态码变化：403、400、500 可能表示过滤拦截；200 但内容异常才更危险
- 响应长度突变：过滤后返回空内容、默认提示页，长度明显缩短
-
关键字符串缺失：原始 payload 中的特殊字符（如
、'）在响应中被删除、转义（变成）或替换为空格 - HTML/JS 解析行为：用浏览器实际加载响应，检查 DOM 是否被破坏、事件是否绑定成功、脚本是否执行
推荐在 Burp 中开启 “Response comparison” 功能，将正常请求与 payload 请求并排对比；也可用 Python 脚本自动提取响应中的 <script></script> 标签数、alert 出现次数等指标。
四、验证绕过路径并定位缺陷环节
发现过滤失效只是开始。要进一步确认是哪一层出了问题：
- 若大小写变形（
SeLeCt）或添加空格（SEL ECT）即可绕过 → 表明过滤器未做标准化预处理 - 若双写（
selselectect）被截断后剩select→ 说明存在“黑名单截断”逻辑缺陷 - 若在 Cookie 中注入成功但在 URL 参数中失败 → 暴露过滤机制未统一覆盖所有入口点
- 若时间盲注（
sleep(5)）响应延迟显著 → 说明后端仍拼接执行，过滤仅作用于前端或 WAF 层
此时应结合抓包、服务端报错信息（如有）、以及 WAF 响应头（如 X-WAF-Status）交叉分析，明确漏洞根因落在应用代码、中间件还是边界防护设备上。
