渗透考题

去年秋天，渗透考题我在一个安全培训课上碰到一道题，渗透考题至今记得。渗透考题题目给了一段看似正常的渗透考题HTTP请求日志，要求判断是渗透考题否存在SQL注入。大部分人扫了一眼就跳过了——参数里没有单引号，渗透考题没有or 1=1，渗透考题也没有union select。渗透考题但答案偏偏是渗透考题"存在"。

出题人把注入点藏在了User-Agent头里。渗透考题那段字符串经过三次URL编码，渗透考题解码后是渗透考题一段sleep(5)的盲注payload。这个细节让我意识到，渗透考题渗透测试的渗透考题考题从来不是在考你背了多少条规则，而是渗透考题在考你愿不愿意多看一眼。

那些"看起来没问题"的地方

我后来自己搭了一套靶场，专门复现这类场景。有一次把注入点放在Cookie的session_id字段里，格式伪装成32位十六进制字符串。十个来试的人里，有七个直接判定"这是哈希值，不可控"。剩下三个里，两个试了单引号发现报错被WAF拦了，就放弃了。只有一个哥们儿注意到，把最后一位从a改成b时，页面返回时间多了两秒。

这就是渗透考题的典型套路：它不考你知不知道' or '1'='1，它考的是你有没有形成"每个输入点都值得怀疑"的本能。这种本能没法靠刷题刷出来，得靠一次次踩坑喂出来。

考题背后的真实逻辑

很多渗透考题喜欢在"不可能的地方"做文章。比如一个只接受数字的id参数，你传1 and 1=1它返回正常，传1 and 1=2它返回空白——这说明它把整个字符串带进了SQL查询，而不是先做类型转换。这种"数字型注入"在真实业务里比字符型更常见，因为开发觉得"我都限制你只能输数字了，总安全了吧"。

还有一类考题专攻逻辑漏洞。比如修改密码的接口，正常流程是POST /change_pwd带上old_pwd和new_pwd。考题会让你尝试删掉old_pwd字段，或者把user_id改成别人的。这类题没有固定payload，全看你对业务逻辑的理解。我见过最绝的一道题，是让你通过修改HTTP方法从POST变成PUT，直接绕过了整个鉴权中间件——因为那个中间件只拦截了POST请求。

为什么你总是漏掉那个点

说白了，大部分人在做渗透考题时，脑子里跑的是"检查清单"：XSS试了没？SQL注入试了没？文件上传试了没？这种线性思维在遇到"组合拳"时就会崩。比如一道题同时涉及SSRF和Redis未授权，你需要先用SSRF打内网，再用gopher协议写crontab。 checklist上根本没有这一项。

我自己总结下来，漏掉关键点的原因通常就两个：一是对"正常"的定义太窄，觉得只有带参数的URL才叫输入点；二是对"异常"的容忍度太高，看到500错误就以为是服务器问题，看到延迟就以为是网络抖动。渗透考题恰恰是在这两处下钩子。

一点实在的建议

如果你在准备这类考试，别光刷题库。找个靶场，把每个请求都拦下来，逐个字段改一遍。改的时候别只想"这里能不能注入"，多想一步"如果这里能注入，后端代码大概长什么样"。这种"逆向推理"的习惯，比记住一百个payload管用。

另外，别迷信工具。sqlmap跑不出来的地方，手动加个%00截断可能就通了。考题设计者往往就是算准了你会依赖自动化工具，才把漏洞藏在那些工具默认不检测的角落。

最后说个真事。有个朋友考OSCP时，卡在一台机器上整整两天。最后发现入口是一个.git目录泄露，而那个目录的返回码是403——工具默认跳过403。他手动改了个User-Agent，403变成了200。你看，考题从来不难，难的是你愿不愿意在"没路"的地方多踩一脚。