3.2 Repeater请求重放与手工验证

3.2 Repeater请求重放与手工验证

本节摘要：Repeater 是把"怀疑"变成"结论"的车间：取一条请求，改一处，发一次，对比响应差异，循环往复直到能下判定。本节给出一套可复用的重放工作法，并用靶场上的越权验证案例走完整流程——这是全书最重要的一节，自动化模块的判定标准都在这里确立。

重放是手工测试的心跳

站点地图给了疑点清单，本节解决"疑点怎么处理"。重放的思维方式一句话能说清：控制变量。一次只改请求的一个位置，其余保持不动，响应的任何变化就都能归因到这一处修改。新手最常见的低效不是不会改包，而是一次改五处再猜哪处起效；职业做法相反，改一处、看一眼、记录、再改下一处。

把请求送进重放器的方式已经见过：从历史或地图右键发送。工作区左右分栏，左侧请求可自由编辑，右侧响应随每次发送刷新，历史发送留在标签页里可回溯。配合 3.1 节的地图习惯，重放里的每条重要请求也值得送回地图并标注——证据链在工具内自洽，报告阶段不慌。

判定要看什么？响应差异有三个层次的观察点。状态行与长度变化最直观，长度差异常先于可见内容差异暴露问题；头部变化藏着行为线索——缓存指令、会话设定、跳转目标；消息体变化是最终判据，重点看结构性差异（多了字段、状态翻转）而非只搜关键词。工具的差异比较功能（与编码解码面板一起，构成重放的两个辅助件）能把两次响应逐行对比，肉眼扫不出的字节数级差异在这里现形。

图：一次重放验证的判定回路

案例实录：靶场上的水平越权验证

背景。靶场注册了两个练习账号，低权账号浏览订单时注意到地址栏里的订单号是连续数字。假设：服务端取单据时只认单号、不校验归属。

操作。把该请求送入重放器。第一步取基线：原样发送，确认当前账号正常拿到自己的单据——重放的第一条纪律永远是先取未修改的基线响应。第二步做单点修改：只把单号参数换成自己另一个账号的单号，其余一字不动，发送。

GET /order/detail.php?order_id=1002 HTTP/1.1
Host: lab.local:8088
Cookie: PHPSESSID=lowprivsession

HTTP/1.1 200 OK
Content-Length: 1487

...订单详情，含另一账号的收货人姓名与金额...
​

结果。状态行不变、响应长度变化明显，消息体返回了另一个账号订单的完整内容。

解读。基线与变体之间唯一的变量是单号参数，响应却从"自家单据"变成"他账号单据"，归属校验缺失的判定成立。证据三件套齐了：修改前的请求与响应、修改后的请求与响应、判定依据一句话——服务端未校验资源归属与会话身份的一致性。

变式。单号是连续数字，意味着还存在枚举面——批量验证交给第四章的攻坚模块。但注意本节判定已经足够支撑报告条目：批量只是量化影响范围，不是证明问题存在的必要条件。经验不足者常在这里倒置优先级，花一下午做枚举，报告里却没说清判定依据。

重放的两条纪律

一是请求卫生：重放会产生大量相似请求，测试结束前把验证类请求集中归档标注，别让它们淹没在历史里；涉及真实数据的评估，验证用数据用完即弃。二是节奏：重放适合"想清楚再点发"的节奏，它不限制速率，但你的判定质量限制在每一次修改的清晰度上。

响应观察的四个陷阱

对比响应看似直观，实际有四个高频陷阱，逐个说清。缓存：同一请求两次发送响应不同，先怀疑缓存——可能是代理与目标之间的缓存层，也可能是目标自身的缓存；处置办法是加一个无副作用的随机参数强制穿透，或在头部显式声明不要缓存。动态令牌：表单类请求常带一次性令牌，重放被拒不代表行为有异，可能是令牌过期——正确做法是先取新令牌再重放，验证时把令牌获取也纳入步骤。时序噪音：响应时间天然波动，以时间为判据的验证必须多次取样，单次的时间差不构成证据。会话状态：前一次重放可能改变了服务端状态（比如尝试次数计数），导致后续重放行为漂移——需要时重新登录取干净会话，保持每轮验证的初始状态一致。

这四个陷阱的共同解药是对照意识：任何观察都要有干净的对照组。基线请求、变体请求、再取一次基线——三点连线才是可信的观察。只看变体的"异常"就下结论，是新手报告里大量误报的来源。

重放器里的加减法

加法是增强观察：把请求的关键参数与响应里的关键信号做成对照笔记；用差异比较工具把两次响应的逐行差异拎出来；给关键验证请求做标注回链地图。减法是控制变量：一次只改一处之外，还要克制"顺手多试几个"的冲动——灵光一现的思路记下来排队，按队列逐个验证，比当场乱枪打鸟的效率高得多。这套加减法在熟练之后会内化成节奏感：什么时候该停下来说"这个方向证据够了"，与"再试一次"的边界，就是手工测试的手艺所在。

还有一条针对长会话的经验：重放做到半天之后，人对"什么是正常响应"的记忆会漂移。定时回看几个基线请求——最初取的正常样本如今还正常吗？漂移可能来自你的会话状态，也可能来自目标侧的变更。早发现漂移，早止损重置，比在错误的基线上继续累积变体划算得多。

高频疑问

问：重放请求被拒绝，怎么区分"验证成功"与"步骤做错了"？
答：看拒绝的原因。参数校验类拒绝（格式、令牌）说明步骤要修；权限类拒绝（拒绝访问、统一错误页）可能正是要找的行为差异。把拒绝响应与正常业务里的同类拒绝做对照，是区分两者的关键动作。

问：一条请求改了十几处都不见效，该放弃吗？
答：先回到基线自检：原始请求原样发送是否行为正常？环境是否漂移？都正常仍无进展，把当前尝试记录后转下一个疑点——手动测试的时间盒纪律。这个疑点留给批量或隔天再看的情形都很常见。

问：重放会产生大量相似请求，目标侧会不会告警？
答：会，节奏失控的重放在有监测的目标上就是一次显眼的异常。评估环境里这通常无妨且应在计划中说明；生产环境的手工验证也要控制节奏与总量——这个意识与第四章的速率纪律同源。

与后续章节的接口

当同一判定标准需要套用到成百个输入上——枚举、字典、边界值——就是转场第四章的时机。带着本节确立的判定标准过去：批量模块跑完的每一类结果，都要能回答"这在重放器里意味着什么"。

本节要点回顾

• 心法：控制变量，一次改一处，先取基线再做变体。
• 观察：状态与长度看趋势，头部看行为，消息体看结构，差异比较工具补盲区。
• 判定：坐实与排除都记录，判定依据写成一句话，证据三件套齐活。
• 边界：重放负责证明，批量负责量化，别在重放阶段做机器的活。