去年秋天，渗透试我帮一个做电商的性测朋友检查他刚上线的后台系统。他挺自信，渗透试说用了最新的性测框架，还买了SSL证书，渗透试“安全应该没问题”。性测我没吭声，渗透试打开浏览器代理，性测抓了几个请求，渗透试十分钟后在他数据库里看到了管理员密码的性测明文存储。他脸都绿了。渗透试

渗透性测试不是性测拿着扫描器跑一遍就完事。那些自动化工具能告诉你“这个端口开着”“那个版本有已知漏洞”，渗透试但真正的性测风险往往藏在逻辑里。比如一个优惠券功能，渗透试工具只会测SQL注入，可你手动试试把数量改成负数，或者把用户ID换成别人的，可能就能零元购。这种事我见过太多次。

说个具体手法。有次测试一个预约系统，正常流程是选时间段、填信息、提交。我拦截了提交请求，发现它只在前端验证了时间段是否可选。后端呢？直接信任了传过去的参数。我把已约满的时间段ID改了一下，居然预约成功了。这不算什么高级漏洞，但造成的后果是真实的——用户可以抢占别人的时间。

工具扫不出来的还有权限问题。很多系统用“隐藏菜单”来假装权限控制，普通用户看不到管理按钮，但接口没做校验。你只要知道URL，或者抓包改个role参数，就能干管理员的活。我习惯用Burp Suite的Repeater功能，把普通用户的Cookie换到管理员接口上，看返回什么。十次里有三次能得手。

别迷信“内网就安全”。我做过一个项目，测试目标在内网，开发觉得外面打不进来。结果呢？我通过一个SSRF漏洞，让服务器自己请求了内网的Redis，写了个计划任务，直接反弹shell。整个过程没用到任何0day，全是配置疏忽。内网横向移动比外网容易多了，因为信任关系到处都是。

渗透测试报告怎么写也有讲究。见过太多报告，列一堆“高危”“中危”，修复建议就一句“请升级到最新版本”。这没用。开发需要的是可操作的步骤：哪个文件、哪行代码、改成什么样。我习惯附上复现的HTTP请求原始报文，再给一个修复后的示例。有次我指出一个文件上传漏洞，开发说“我限制了后缀名”。我当场把shell.php.jpg传上去，他就不说话了。后来他改成白名单校验，还加了内容检测，这才算完。

成本也是个现实问题。小公司请不起专业团队，自己又不懂。我的建议是，至少做一次基础测试：用OWASP ZAP跑一遍，手动试试越权、支付逻辑、验证码复用。别等出了事再补。去年有个客户被薅了十几万的羊毛，就是因为注册接口没限制频率，被人用脚本批量领新人券。这种漏洞，一个简单的限流就能防住。

最后说个观察。很多漏洞的根源不是技术，是心态。开发觉得“没人会这么无聊来测”，产品觉得“先上线再说”。渗透测试就是扮演那个“无聊的人”，在你上线前把坑踩一遍。疼，但比上线后被真实攻击强。

(责任编辑：百科)