渗透测试不是渗透拿着扫描器跑一遍就完事。去年我帮一家做跨境电商的测试朋友看他们刚上线的支付网关，甲方自己的内容安全团队用商业扫描器跑了三遍，报告里全是渗透“低危”“信息泄露”这类不痛不痒的条目。我花了一个下午，测试只做了一件事：把他们的内容优惠券领取接口里的手机号参数从 13800138000 改成 13800138001，然后重放请求——服务器返回了另一个用户的渗透优惠券列表。这就是测试渗透测试和漏洞扫描的区别。扫描器告诉你“这里可能有问题”，内容渗透测试告诉你“我进来了，渗透这是测试证据”。

具体测什么？内容拿Web应用来说，身份认证环节永远是渗透重灾区。我习惯先看登录接口有没有撞库防护，测试验证码是内容不是前端校验，JWT令牌能不能改算法为none。有一次遇到一个系统，登录失败五次锁定账户，但锁定的是用户名而不是IP——我换个用户名继续试，照样能撞。这种逻辑漏洞扫描器根本发现不了，得靠人手动构造请求。授权问题更隐蔽。把URL里的 /user/123/profile 改成 /user/124/profile，如果能看别人的资料，那就是水平越权。垂直越权则是普通用户直接访问管理员接口，比如 /admin/deleteUser?id=5，很多系统只在前端隐藏了按钮，后端根本没校验角色。

注入类漏洞这些年少了，但没绝迹。SQL注入现在多半出现在排序参数、JSON字段或者冷门的老接口里。我见过一个导出Excel的功能，orderBy 参数直接拼进SQL，用报错注入能拖出整个用户表。命令注入更少见，可一旦碰上就是高危。文件上传也是老生常谈，但绕过方式一直在更新——改Content-Type、加.jpg后缀再配合解析漏洞、或者上传.htaccess让图片当脚本执行。去年有个案例，上传点只检查文件头是不是GIF89a，我在文件开头加这两个字节，后面跟PHP代码，服务器照样解析。

业务逻辑漏洞才是渗透测试里最费脑子也最有意思的部分。比如密码找回，验证码返回在响应包里，或者修改手机号时没校验原号码。支付环节更夸张：把商品数量改成负数，总价变成负的，平台反而给你打钱。还有并发问题——同一张优惠券同时提交一百次请求，如果数据库没加锁，可能核销多次。这些场景没有固定套路，得把自己当成产品经理去理解业务流，然后找那条“设计者没想到的路径”。

内网渗透往往从一台Web服务器开始。拿到shell后先看 whoami 和 ipconfig，然后翻配置文件找数据库密码、Redis密码、云AK/SK。横向移动常用的是永恒之蓝、Redis未授权写SSH公钥、或者抓取内存里的明文密码。域环境里，Kerberoasting和AS-REP Roasting是标配，Golden Ticket看情况用。但内网不是每次都能打进去，有时候一个弱口令的Tomcat管理后台就足够了——部署war包拿shell，比费劲找漏洞快得多。

最后说报告。渗透测试的产出不是“发现了10个高危”，而是按业务影响排序的修复建议。一个能直接转走资金的逻辑漏洞，优先级远高于十个反射型XSS。我写报告时会把复现步骤写得像菜谱：请求包、响应包、截图、影响范围、修复方案。甲方要的是能落地的东西，不是CVSS评分。测完记得清理webshell和测试账号，别给人家留后门——这行口碑比技术更重要。