去年冬天，渗试我帮一家做跨境电商的透测小公司做了一次渗透测试。目标是渗试一个看起来挺普通的登录页面，输入框、透测密码框、渗试验证码，透测没什么特别。渗试但当我用Burp Suite抓包改了一下请求参数，透测把 user_id=123 改成 user_id=124，渗试页面直接返回了另一个用户的透测订单列表。水平越权，渗试就这么简单。透测老板当时脸都绿了——他以为前端做了校验就安全了。渗试

这件事说明一个挺朴素的透测道理：Web渗透测试不是拿着扫描器跑一遍就完事。工具能帮你发现SQL注入、渗试XSS这些常见漏洞，但逻辑漏洞、权限设计缺陷，往往得靠人一点点去试。我习惯先手动走一遍业务流程，注册、登录、下单、改密码，每个环节都抓包看看参数怎么传的。很多问题就藏在这些“正常操作”里。

信息收集阶段，别只盯着域名和IP。我通常会翻一遍目标网站的robots.txt、sitemap.xml，甚至用Google语法搜 site:target.com inurl:admin。有一次在一个客户的后台路径里发现了 /backup/2023.zip，下载下来是整站源码。省了太多事。这种低级失误现在依然常见，尤其是外包项目交接的时候。

说到漏洞利用，SQL注入没以前那么多了，但二次注入和盲注还是能碰到。我更喜欢找文件上传点。有个案例：上传头像的地方只检查了Content-Type，改成 image/jpeg 就能传 .php 文件。更离谱的是，上传后的路径直接返回在响应里，连爆破目录都省了。拿到shell之后，内网横向移动就是另一回事了——不过那是后话。

XSS现在挺难利用的，因为现代框架默认转义。但存储型XSS在评论区、用户名这些地方还是有机会。我试过在个人简介里插入 <img src=x onerror=alert(1)>，结果管理员后台审核时触发了。这种漏洞单独看危害不大，配合CSRF就能干点坏事。比如伪造管理员发公告，或者偷cookie——如果cookie没设HttpOnly的话。

CSRF的防御现在基本靠token，但有些老系统还在用Referer校验。Referer是可以伪造的，或者用 data: 协议绕过。我遇到过一个银行系统，修改密码的请求没有token，只靠一个 old_password 参数。攻击者只要诱导用户访问一个恶意页面，就能悄悄改掉密码。这种设计放在今天，实在说不过去。

渗透测试报告怎么写，也是个技术活。别堆砌漏洞名称和CVSS评分，客户看不懂。我一般按业务影响来分：能直接拿数据的、能控制服务器的、能影响其他用户的。每个漏洞配上复现步骤和截图，再给个修复建议。比如“在服务端校验user_id是否属于当前会话”，而不是“加强输入过滤”这种废话。

最后说个观察：很多公司做完渗透测试，修了报告里写的漏洞，但没修同类问题。比如修了 /api/v1/user 的越权，忘了 /api/v2/user 也有。或者修了登录处的SQL注入，忘了注册处。所以复测的时候，我习惯把同类接口都扫一遍。安全不是打补丁，是改设计。

工具永远在变，Burp、sqlmap、nuclei，用顺手的就行。但思路比工具重要。理解HTTP协议、理解业务逻辑、理解开发者的偷懒习惯——这些才是渗透测试的核心。下次你看到一个登录框，别急着丢sqlmap，先想想：如果我是开发者，我会在哪里留后门？