2. HTTP请求响应手工分析与安全关注点标注
为什么手工分析请求比“扫一遍”更有价值
代理工具能自动记录流量，但真正的安全测试点往往藏在字段语义里：role=user 能否改成 admin？price=99 是否由前端传入？Cookie 里有没有可预测的会话标识？这些判断无法靠扫描器完成，必须逐字段阅读。本案例以 DVWA 登录、搜索、上传三个请求为对象，建立一套可复用的字段标注方法。
截获与标注流程
在浏览器代理已指向本地监听端口（如 8080）的前提下，开启拦截，依次触发登录、搜索、上传动作，对每个请求暂停并记录。标注时按“位置 → 值 → 可疑点 → 验证动作”四列推进，不要只截不析。
三个典型请求的字段标注示例
| 请求 | 字段 | 原值 | 可疑原因 | 验证动作 |
|---|---|---|---|---|
| 登录 | username | admin | 直接进入 SQL 查询 | 改为 admin' -- 重放，观察是否登录成功或报错 |
| 登录 | Cookie: security | low | 安全等级由客户端控制 | 改为 high 重放，确认服务端是否信任该值 |
| 搜索 | search | test | 回显到页面 | 改为 <script>alert(1)</script>，观察是否原样输出 |
| 上传 | uploaded | shell.php | 扩展名与 MIME 校验 | 改为 shell.php.jpg 或修改 Content-Type 重放 |
| 上传 | MAX_FILE_SIZE | 100000 | 客户端限制 | 改为更大值，确认服务端是否独立限制 |
用重放对比确认判断
标注只是假设，必须通过“改一个字段、其余不变”的重放来验证。以搜索请求为例：
原始请求：
GET /dvwa/vulnerabilities/xss_r/?search=test&Submit=Submit HTTP/1.1
Host: 192.168.1.10
Cookie: PHPSESSID=8f3a...; security=low
重放请求（仅改 search）：
GET /dvwa/vulnerabilities/xss_r/?search=%3Cscript%3Ealert(1)%3C%2Fscript%3E&Submit=Submit HTTP/1.1
Host: 192.168.1.10
Cookie: PHPSESSID=8f3a...; security=low判断依据：若响应体中 <script> 未被转义且浏览器执行弹窗，则确认反射型 XSS；若被转义为 <script>，则说明该点已做输出编码，应转向其他参数或编码绕过方式。
标注时优先关注三类字段：直接进入后端逻辑的（username、search、uploaded）、控制安全策略的（security、role、isAdmin）、控制会话的（PHPSESSID、token）。这三类字段的篡改收益最高。
不要只截获登录请求就结束。搜索、上传、评论、排序、分页等参数往往比登录更容易暴露注入与 XSS，且常被测试者忽略。每个功能点至少标注一个请求。
标注检查清单
- 请求行：方法是否可替换（GET↔POST）、路径是否可绕过认证。
- 请求头：Cookie 属性、Referer 校验、Host 注入、自定义头信任。
- 请求体：每个参数是否被服务端重新校验、是否存在隐藏字段、是否可越权改值。
- 响应：Set-Cookie 属性、错误回显、状态码与重定向、Content-Type。
- 验证：每次只改一个字段，记录响应差异，区分“前端限制”与“服务端限制”。