凌晨两点，安全我盯着屏幕上的测试HTTP响应包，第五次确认那个参数确实没做过滤。工程数据库里躺着三万条用户记录，安全其中一半是测试手机号。这不是工程什么高深的技术活，就是安全耐心活——把每个输入点都当成罪犯来审。

安全测试工程师干的测试活儿，说白了就是工程找茬。但找茬也有讲究，安全不是测试拿个扫描器跑一遍就完事。上个月我测一个金融APP，工程扫描器报了十几个漏洞，安全全是测试无关痛痒的反射型XSS。真正要命的工程逻辑漏洞藏在支付流程里——修改订单金额后重放请求，服务器居然照单全收。这种漏洞，工具永远发现不了，得靠人脑去模拟攻击者的思路。

干这行三年，我总结出一条铁律：开发人员觉得"没人会这么干"的地方，恰恰是漏洞最密集的区域。比如某个导出Excel的功能，谁会在文件名后面加单引号？黑客会。就这一条，我上周在某政府网站的系统里直接拿到了服务器权限。不是技术多高明，就是试了试开发没想过要防的场景。

有时候觉得自己像个职业怀疑论者。看到登录框，第一反应是SQL注入；看到文件上传，立刻想到webshell；看到加密参数，本能地开始尝试篡改。这种思维模式会渗进生活——扫码支付时我会想，这个二维码能不能换成恶意链接？电梯里的广告屏，是不是存在未授权访问？
但这份工作最迷人的地方在于，你得永远比攻击者多想一步。他们利用的是逻辑漏洞，你就要用逻辑去对抗逻辑。去年某电商平台搞促销，优惠券叠加规则有缺陷，理论上可以无限套用。我花了三天时间，用Python脚本模拟各种组合，最后在某个角落找到了突破口。提交报告时我特意注明：这不是代码层面的bug，是业务设计上的漏洞。

测试报告写出去，反馈往往两极分化。懂行的开发会拍着大腿说"这都能被你想到"，不懂行的会觉得你在找茬。遇到后者，我会把攻击过程录屏，一步步演示给他们看。当屏幕上真的弹出数据库内容时，那种沉默比任何技术认证都有说服力。

这行当入门容易，精通难。工具谁都会用，但判断什么该测、什么值得深挖，靠的是经验堆出来的直觉。我见过太多新人拿着Burp Suite到处乱点，却不知道真正的高价值目标往往藏在业务逻辑的夹缝里。安全测试不是流水线作业，更像是在跟看不见的对手下棋——你永远不知道下一步会踩到什么，但必须时刻准备着应对。

今天下午又要测一个新系统。我泡了杯浓茶，把接口文档打印出来，开始逐个参数地推演。这活儿没有捷径，唯一的技巧就是把自己想象成一个既聪明又执拗的坏蛋，然后不达目的不罢休。当然，最后别忘了写报告的时候，把漏洞描述得让开发心服口服。