去年有个朋友找我，渗透说他们公司花三万块请人做了一次渗透测试，测试报告交上来四十多页，入门全是教学漏洞列表和风险等级，开发看完直接扔一边了。渗透问题出在哪？测试渗透测试不是交报告就完事，它得能落地。入门你告诉开发“这里存在SQL注入”，教学不如直接告诉他“用这个payload能把用户表拖出来”。渗透

渗透测试的测试核心就一句话：模拟攻击者的思路，用合法手段找出系统里能被利用的入门弱点。注意“能被利用”这四个字。教学扫出一堆端口开放、渗透版本信息泄露，测试那叫漏洞扫描，入门不叫渗透测试。真正的渗透测试得证明这个漏洞能造成实际影响。

先搞清楚你在测什么

拿到一个目标，别急着掏Nmap。先问清楚：是测Web应用、移动App、内网还是无线？范围包括哪些IP、域名、账号？有没有禁止测试的时段或系统？我见过有人没确认范围就去扫客户的生产数据库，结果触发告警，项目直接终止。

授权文件必须白纸黑字。邮件确认也算，但最好有正式签署的SOW，写清楚测试时间窗口、允许的技术手段、紧急联系人。别嫌麻烦，这是保护你自己。

信息收集决定上限

渗透测试的深度，八成取决于信息收集。很多人上来就对着登录框一顿爆破，效率极低。先看看目标用了什么框架、什么中间件、有没有暴露的API文档、GitHub上有没有员工不小心提交的密钥。

举个例子。某次我测一个电商站，主站防护很严，WAF拦得死死的。但通过子域名枚举发现一个测试环境，test-shop.example.com，上面跑着同样的代码，却没有WAF。从测试环境的报错信息里拿到数据库版本，再结合已知漏洞，二十分钟拿到shell。主站？根本没碰。

工具方面，subfinder、httpx、nuclei这三件套够用很久。但别当脚本小子，每个结果都手动看一眼。

漏洞验证要讲证据

发现疑似漏洞后，第一反应不是兴奋，是冷静验证。SQL注入？先手工加个单引号看报错，再用sqlmap跑，但记得加--technique和--risk限制，别把库拖崩。XSS？弹个alert(1)只是第一步，得证明能窃取Cookie或者发起CSRF。

文件上传漏洞更典型。上传一个.php被拦了，试试.phtml、.php5、大小写混合、加个空格或者点。这些绕过手法不是玄学，是开发配置疏漏的常见表现。我电脑里有个文本文件，专门记这些payload，用了六年还在更新。

别忽视逻辑漏洞

技术漏洞有扫描器帮忙，逻辑漏洞只能靠脑子。比如密码重置功能，验证码返回在响应包里、或者修改手机号就能重置任意账户。再比如支付环节，把商品数量改成负数、或者把价格参数从小数改成整数溢出。这些漏洞扫描器扫不出来，但危害往往更大。

有个经典案例：某平台优惠券领取接口没做频率限制，用Burp的Intruder跑一万次，领了一万张券。开发觉得“谁会这么干”，攻击者觉得“这不明摆着送钱”。

报告写成开发能看懂的样子

漏洞标题写“SQL注入”不如写“用户搜索接口存在SQL注入，可读取全库数据”。复现步骤要带请求包和响应包截图，修复建议要具体到代码层面。比如“使用参数化查询”比“过滤特殊字符”有用得多。

风险等级别乱标。一个需要物理接触才能利用的漏洞，标成“高危”只会让客户觉得你不专业。CVSS评分可以参考，但最终要结合业务场景判断。

渗透测试入门不难，难的是保持好奇心和耐心。工具会过时，思路不会。下次拿到目标，先花半小时想想：如果我是攻击者，我会从哪里下手？

(责任编辑：热点)