拿到一份渗透测试报告，渗透翻到"漏洞详情"那一页，测试满屏的代码``和`' OR 1=1 --`，说明测试人员只干了半件事。渗透真正有价值的测试渗透测试代码，不在报告里，代码在测试过程中那些改了三版才跑通的渗透脚本里。

我见过太多人把渗透测试等同于打开Burp Suite点几下扫描。测试工具能帮你发现已知模式的代码漏洞，但业务逻辑漏洞、渗透权限绕过链、测试多步骤组合攻击，代码工具根本看不懂。渗透这时候你得写代码。测试不是代码写exp那种"一键getshell"的脚本，而是写能理解目标系统行为、能模拟真实攻击路径的代码。

举个具体例子。某次测试一个电商后台，扫描器报了一堆低危XSS，但真正致命的是订单退款接口的越权问题。怎么发现的？写了个Python脚本，用普通用户token遍历退款订单ID，发现能操作别人的订单。代码本身很简单，核心就几行：

for order_id in range(10000, 10100): r = requests.post(f"{ base}/api/refund", headers={ "Authorization": f"Bearer { user_token}"}, json={ "order_id": order_id, "reason": "test"}) if r.status_code == 200: print(f"越权成功: { order_id}") 

这玩意儿扫描器扫不出来。因为它需要理解"退款"这个业务动作的语义，需要知道订单ID的生成规律，需要有一个合法的普通用户身份。这些都是代码之外的东西，但代码把它们串起来了。

渗透测试代码的另一个价值在于可重复性。手工测试时你点了一个按钮触发了漏洞，回头想复现，发现忘了当时点了哪个参数、哪个header。写成代码就不一样了，参数、顺序、依赖关系全在脚本里。下次回归测试，直接跑一遍，五分钟出结果。

但别走极端。我见过有人花三天写了个"全自动渗透框架"，结果目标系统改了个字段名，整个脚本报废。渗透测试代码要写得"糙"一点——硬编码几个关键参数没关系，异常处理不用面面俱到，能跑通当前目标就行。过度工程化是渗透测试代码的大忌。

还有个细节：注释。不是写给老板看的，是写给三个月后的自己看的。比如# 这里必须用PUT不能用POST，否则WAF会拦，或者# token有效期只有5分钟，跑完一轮要重新登录。这些信息报告里不会写，但下次测试同一个系统时，能省你半天时间。

说到底，渗透测试代码是你和系统之间的对话记录。扫描器说的是"这里可能有问题"，代码说的是"我试过了，确实有问题，而且我知道怎么利用"。这两者之间的差距，就是渗透测试工程师和脚本小子的差距。

下次写渗透测试代码时，别想着写得多优雅。想着怎么用最短的代码路径，触达最深的业务逻辑。跑通那一刻的print("success")，比任何报告里的"高危漏洞"四个字都实在。