去年冬天，网页我帮朋友看一个刚上线的渗透电商站点。服务器在境外，测试页面加载慢得离谱，网页但这不是渗透重点。重点是测试我在URL里加了个单引号，页面直接吐出一段MySQL错误——数据库版本、网页表名、渗透甚至部分字段都露出来了。测试这就是网页网页渗透测试里最经典的入口：SQL注入。很多人以为这种漏洞早绝迹了，渗透现实是测试，它还在，网页只是渗透藏得更深。

渗透测试不是测试拿工具扫一遍就完事。工具能告诉你“这里可能有注入点”，但真正判断能不能利用、怎么利用、影响范围多大，得靠人。比如那个电商站，sqlmap跑一遍确实报了注入，但默认的payload被WAF拦了。我换成大小写混合加内联注释，绕过去了。数据库是MySQL 5.7，权限没做限制，直接load_file读到了/etc/passwd。朋友当时脸都白了。

XSS的情况更微妙。反射型XSS现在很多浏览器自带过滤，但存储型不一样。有个论坛类站点，用户签名档允许HTML，但过滤了<script>。我试了<img src=x onerror=alert(1)>，没反应。换成<svg onload=alert(1)>，弹窗了。后来发现它只黑名单了script标签和on开头的事件属性，但svg的onload不在黑名单里。这种绕过思路，扫描器基本扫不出来。

文件上传是另一个重灾区。有个后台允许上传头像，前端校验了后缀名，后端也校验了MIME类型。看起来挺严。但后端校验MIME时只检查了Content-Type头，没检查文件内容。我把shell.php的Content-Type改成image/jpeg，上传成功。然后访问/upload/shell.php，直接拿到webshell。整个过程不到三分钟。这种漏洞的根源是开发者信任了客户端发来的数据——渗透测试的核心逻辑就是：永远不要信任客户端。

CSRF经常被忽略。有个后台管理功能，删除用户只需要发一个GET请求，参数是user_id。没有token，没有Referer校验。我构造了一个页面，里面放一张图片，src指向删除用户的URL。管理员一打开这个页面，用户就被删了。这种漏洞利用成本极低，但危害不小。很多开发者觉得“管理员不会乱点链接”，但钓鱼邮件里放个链接，点一下太容易了。

渗透测试的流程其实很固定：信息收集、漏洞探测、漏洞利用、权限提升、痕迹清理。但每一步的细节千差万别。信息收集阶段，我习惯先看robots.txt和sitemap.xml，经常能发现没公开的目录。有一次在robots.txt里看到Disallow: /backup/，访问进去发现整个数据库的SQL备份文件。这种事听起来离谱，但每年都在发生。

工具方面，Burp Suite是标配，但别迷信它的自动扫描。我更多用它来抓包和重放请求，手动测试参数。Nmap用来扫端口，但有时候目标只开了80和443，其他端口全过滤，这时候就得从Web应用本身找突破口。Dirsearch跑目录，但字典得根据目标定制。比如目标是个Java站，就重点跑.action和.do后缀。

说个具体的案例。某次测试一个政府站点，前台看起来很正常。我注意到URL里有id=123这样的参数，试了id=123'，报错。试了id=123 and 1=1，正常。id=123 and 1=2，空白。确认注入。但WAF拦了union select。我换成union/**/select，绕过了。然后查information_schema，拿到管理员表名和字段。密码是MD5，cmd5解不出来。但我在同一个数据库里发现了另一个表，存着明文密码——他们内部系统用同一套密码。直接登录后台，上传webshell，完事。

渗透测试报告怎么写？别堆砌漏洞名称和CVSS评分。客户要的是：这个漏洞怎么复现、影响什么、怎么修。我习惯每个漏洞配一张截图，加上具体的请求和响应。修复建议要具体到代码层面，比如“在SQL查询中使用参数化查询，替换字符串拼接”。别写“加强输入验证”这种废话。

最后说个观察。很多站点在渗透测试后修了漏洞，但过几个月再看，又出现了。原因是开发人员换了，或者新功能上线时没做安全评审。渗透测试不是一劳永逸的事，它更像体检——你今年查了没事，不代表明年也没事。真正安全的站点，是把安全融入开发流程，而不是靠一年一次的渗透测试来兜底。