漏洞poc请求包

凌晨两点十七分，漏洞我盯着Burp Suite里那个红色的请求包响应码，手指在键盘上悬了三秒。漏洞401，请求包未授权。漏洞但这正是请求包我要的——目标站点的登录接口对POST参数过滤不严，一个简单的漏洞JSON注入就能绕过认证。我改了请求体里的请求包"role":"user"为"role":"admin"，重放，漏洞200。请求包屏幕绿光一闪，漏洞后台管理面板像熟透的请求包西瓜一样裂开了。

这就是漏洞PoC请求包的全部意义：用最少的字节，验证一个漏洞是请求包否真实存在。它不是漏洞武器，是试纸。像医生用棉签刮喉咙测流感，我构造一个HTTP请求，看服务器会不会在特定参数上“咳嗽”。
一个标准的PoC包通常长这样：POST /api/login HTTP/1.1，Host头，Content-Type，然后是精简的body——往往只有几行JSON或一串URL编码的payload。它不追求攻击效果，只追求“触发”。服务器返回500，说明参数被解析但没处理好；返回200且内容变化，说明漏洞确认；返回302跳转，也许只是被WAF拦了——那又是另一场猫鼠游戏。

记得去年测某个开源CMS，官方补丁说是修复了SQL注入，但补丁只过滤了$_GET，没管$_COOKIE。我构造的PoC请求包里，payload藏在Cookie头的PHPSESSID字段里，用UNION SELECT拼了一个时间盲注。请求包发出去，服务器睡了5秒才响应。那一刻比喝冰可乐还爽——补丁打偏了，漏洞还在血管里跳。

写PoC包是个手艺活。多了冗余字段会被日志系统淹没法，少了必要的请求头可能触发默认拒绝策略。最精妙的PoC往往短得惊人。GET /?id=1'——就这七个字符，能炸出多少没转义的单引号？我见过最狠的一个PoC，整个请求包只有一行：OPTIONS * HTTP/1.1，直接探测服务器是否允许TRACE方法，进而确认XST漏洞。没有body，没有额外头，像一把只有刀刃的匕首。

但别把这玩意儿想得太酷。多数时候PoC请求包是枯燥的调试记录：改一个参数，重放，看响应，再改，再放。一天能跑几百个请求，大部分石沉大海。真正的“一击必杀”只存在于电影里。现实中，你可能要调上两个小时，只为让那个Content-Length算得刚刚好，否则服务端会认为请求不完整，直接断开连接。

有个细节外行不知道：PoC请求包里的时间戳和随机数往往不是乱写的。某些漏洞触发依赖时间窗口或会话状态，请求包里的X-CSRF-Token必须从上一个响应里提取。这就像开锁不仅要选对钥匙，还得在锁芯转到特定角度时捅进去。差一秒，锁就重新咬死。

说到底，PoC请求包是安全研究者的便签纸。它记录的是“这里有问题”的瞬间，不负责解释问题有多深。真正的价值在重放之后——当你盯着那个非预期的响应，脑子里开始推演数据流怎么走到这一步，漏洞的根因才慢慢浮现。请求包只是引子，思考才是正文。
写这篇文章时，我桌面上还躺着白天没测完的那个文件上传点。构造好的PoC包就存在记事本里，十六行，等明天换几个绕过字符再试。夜风从窗缝钻进来，屏幕上的光标还在闪——下一个请求包，或许就能撬开那扇门。