```html

渗透测试需要注意的事项

去年有个朋友接了个私活，给一家小电商做渗透测试。测试他扫完端口直接上了sqlmap，需注结果把人家订单表拖垮了——生产库没做读写分离，渗透事项一条--risk=3的测试注入语句把磁盘IO打满，客服电话被打爆。需注事后甲方没追究，渗透事项但尾款扣了30%。测试这事我记到现在，需注因为很多人栽跟头根本不是渗透事项技术不行，是测试压根没把“注意”二字当回事。

授权书必须白纸黑字，需注扫描范围精确到IP和端口。渗透事项别信口头说“随便测”，测试出了事没人替你扛。需注我见过最离谱的案例：测试人员用nmap扫了整段C类地址，把隔壁公司的ERP系统扫出告警，对方直接报警。授权书里要写明测试时间窗口、允许的测试手法（比如是否允许社工、是否允许拒绝服务类测试）、以及紧急联系人电话。那串电话号码比漏洞报告值钱——半夜三点把生产环境搞挂的时候，你能找到人关防火墙。

生产环境和测试环境永远要分开，但现实里很多甲方只有一套环境。这时候你得主动问：能不能先克隆一份数据到隔离网段？如果不行，把危险操作（比如DROP、UPDATE、批量INSERT）全部禁用。用sqlmap的时候加--technique=B只做布尔盲注，别碰时间盲注。有人觉得这样测不彻底，但把客户业务搞停的“彻底”等于自断后路。我自己的习惯是：凡是可能写数据的Payload，先拿--os-shell里的whoami验证一下权限，确认是只读账号再继续。

别碰真实用户数据。哪怕你拿到了/etc/shadow，也只截图前两行证明可读，别把哈希值往报告里贴。有个同行把某政府站点的管理员密码哈希发到GitHub上“做笔记”，第二天就被请去喝茶。合规的做法是：发现敏感数据后立即停止深入，记录路径和权限，然后通知甲方。如果甲方要求你证明能拖库，用SELECT COUNT(*)代替SELECT *，用LIMIT 1代替全表。这不仅是法律问题，更是职业底线。

时间选择比技术更重要。别在业务高峰期做压力测试，别在周五下午提交高危漏洞报告——运维周末不上班，周一来了发现漏洞已经被利用，你背锅。我一般把扫描任务放在凌晨2点到5点，并且提前跟运维打好招呼：如果看到nmap的SYN包别封IP，那是自己人。另外，测试用的VPS要选和甲方同城市的机房，跨运营商延迟高的时候，hydra跑起来全是超时误报。

报告里别只写“存在SQL注入”，要写清楚：注入点、数据库类型、当前权限、能读取哪些库、修复建议。但修复建议别写“上WAF”这种废话——WAF绕过的姿势比漏洞本身还多。直接给代码级方案：参数化查询、白名单过滤、最小权限原则。我见过最实在的报告，附了一段pytest脚本，甲方开发直接跑一遍就能验证修复效果。

最后说个反直觉的：渗透测试的终点不是拿到root，是让甲方知道自己的风险边界在哪里。你花三天时间从外网打到内网域控，不如花三小时帮他们梳理清楚哪些资产暴露在公网、哪些端口不该开。去年我给一家公司做测试，发现他们测试环境的Redis没密码，但生产环境有。甲方运维说“测试环境无所谓”——结果三个月后，攻击者从测试环境横向到生产环境，数据全丢。所以，别只盯着漏洞，盯着人。

```