应用渗透测试不是应用拿着工具乱扫一通就完事。真正的渗透测试从“信息收集”就已经开始，这一步决定了你后续是测试精准打击还是盲人摸象。我见过太多新手，教程连目标用了什么中间件都没搞清楚，应用就急着跑Nuclei模板，渗透结果打了一堆漏洞报告，测试全是教程误报，最后被客户骂得狗血淋头。应用

信息收集要做的渗透第一件事，是测试搞清楚攻击面。别只盯着主域名，教程去翻证书透明度日志，应用用子域名枚举工具挖出那些被遗忘的渗透测试环境、后台管理面板。测试有个真实案例，一家金融公司让我做测试，主站防护得像铁桶一样，但我在一个叫 dev-payment-api 的子域上找到了未授权访问的Swagger文档，顺着接口直接摸到了生产数据库的连接字符串。那个漏洞要是被恶意利用，后果不堪设想。

拿到足够的攻击面之后，再开始做漏洞扫描。但这里的坑在于，自动化扫描器只能给你一个“疑似”清单。比如SQL注入，工具报了十几个点，可其中一半是WAF拦截后的假阳性。你得学会看原始请求和响应，手动验证每一个可疑参数。把Burp Suite的流量日志导出来，仔细翻看那些带id=、page=之类的参数请求，用单引号和布尔条件去试探响应差异。这活儿枯燥，但却是区分测试员水平的分水岭。

验证漏洞时，有个技巧特别实用——尝试“越权”逻辑。很多应用做了参数校验，却忘了对象级别的权限控制。我测试过一个电商后台，普通用户登录后修改请求里的 user_id 字段，就能直接查看其他用户的订单详情，包括收货地址和手机号。这种漏洞扫描器根本发现不了，完全靠测试者对业务逻辑的理解。你得把自己想象成一个恶意用户，思考“如果我改了这里，系统会不会拦住我”。

再往下说，渗透测试不是只要打进去就完事。拿到一个Shell或者管理员权限后，得做“后渗透”验证。看看能不能提权到root，能不能横向移动到其他内网机器，能不能读取到敏感配置文件。有一次我通过一个文件上传漏洞拿到webshell，本来以为结束了，结果发现同网段还有一台Redis服务没有设密码，直接写入SSH公钥就拿到了整台服务器的root权限。这种连接性，才是真实攻击中真正致命的地方。

写报告的时候，别光贴扫描器的截图。要讲清楚攻击路径——从哪个入口点进来的，用了什么绕过手法，影响了哪些数据。客户需要的是可复现的步骤，不是一堆CVSS分数。我习惯在每个漏洞描述里加上“修复建议”和“验证方法”，比如建议参数化查询、限制对象级别的访问控制，并告诉开发怎么去复测。

最后说点得罪人的话。现在很多企业做渗透测试是为了合规，找家便宜的公司随便扫扫就交差。但真正的安全不是过场。你花一天时间手动测试一个业务逻辑漏洞，比自动扫一千个CVE都有价值。因为攻击者不会按报告里的清单来，他们只会找最脆弱的那条路径。做测试的人，心里得绷着那根弦——如果我是黑客，我会怎么搞垮这家公司。