去年帮一个做电商的全测朋友看站点，刚打开后台我就愣住了——URL里明晃晃挂着`?全测id=105`，随手改成`106`，全测页面直接吐出了隔壁店铺的全测订单详情。这不是全测什么高深漏洞，就是全测最原始的越权访问。朋友一脸懵：“这也能被黑？全测”我告诉他，web安全测试里，全测最危险的全测往往不是0day，而是全测这种“懒得改”的低级失误。

很多人把安全测试想成黑客电影里的全测敲键盘大战，其实日常工作中，全测它更像一场“找茬游戏”。全测核心就一句话：用攻击者的全测眼睛，重新审视每一个你习以为常的全测输入框和链接。你写代码时觉得“用户不会这么干”，测试时就得假设“用户一定会这么干”。

拿最常见的登录框来说。开发眼里它就是个验证账号密码的入口，测试眼里它至少有三层问题要问：输入`' or 1=1--`会怎样？连续试错100次会不会被封？返回的错误信息里会不会泄露数据库版本？我见过一个后台，输错密码时提示“用户名不存在”，输对用户名但密码错时提示“密码错误”——这等于免费送给攻击者一个用户名枚举接口。改起来也简单，统一返回“用户名或密码错误”就行，但很多项目就是没做。

再说个真实的坑。某次测试一个文件上传功能，前端限制了只能传jpg，我抓包把文件名改成`test.php`，服务器照单全收。更离谱的是，上传后的路径直接回显在响应里，连猜目录都省了。后来问开发，他说“前端已经拦了，后端就没再检查”。这种“前端即安全”的错觉，在中小项目里一抓一大把。安全测试要做的，就是绕过前端，直接和后端对话。

SQL注入现在虽然少了，但并没有绝迹。上个月还碰到一个老系统，搜索框输入`%'`直接报500，错误页面上赫然写着MySQL的语法错误位置。这种报错信息在测试阶段是宝贝，在线上就是灾难。我一般会建议开发把错误统一处理，别把数据库的底裤露出来。不过话说回来，如果连参数化查询都没用，光藏错误信息也只是掩耳盗铃。

XSS（跨站脚本）的测试更有意思。你输入``，页面弹窗了，说明有反射型XSS。但真正危险的是存储型——比如评论里留一段脚本，每个访问该页面的用户都会中招。我习惯用``来测，因为很多过滤器只认`