去年秋天，网页我帮朋友看一个刚上线的漏洞电商站点。页面做得挺漂亮，检测功能也正常，网页但他总觉得哪里不对劲——后台偶尔会多出几条莫名其妙的漏洞订单记录，收货地址全是检测乱码。我打开浏览器的网页开发者工具，在搜索框里敲了一个单引号，漏洞页面直接返回了数据库错误信息。检测典型的网页SQL注入，连最基本的漏洞过滤都没做。

这就是检测网页漏洞检测最直接的价值：它不关心你的页面好不好看，只关心别人能不能用它没打算让你用的网页方式，去干些你没打算让他干的漏洞事。

从哪儿开始看

很多人以为漏洞检测得靠专业扫描器，检测其实手动排查往往更有效。我习惯先看URL参数。比如一个链接是 product.php?id=15，把15改成 15' 或者 15 AND 1=1，观察返回内容的变化。如果报错信息里出现了SQL关键字，基本可以确定存在注入点。别小看这个笨办法，我见过不少中型网站连这关都过不了。

表单是另一个重灾区。登录框、搜索框、评论提交——凡是用户能输入的地方，都是潜在的入口。跨站脚本（XSS）就藏在这些地方。测试方法很简单：在输入框里填 <script>alert(1)</script>，提交后看页面是否弹窗。如果弹了，说明服务端没有对输出做转义。更隐蔽的是存储型XSS，恶意脚本被存进数据库，每个访问该页面的用户都会中招。这类漏洞在留言板、用户昵称、商品评价里特别常见。

那些容易被忽略的角落

文件上传功能是我重点盯防的对象。有些开发者只在前端用JavaScript限制文件类型，后端完全不校验。把 shell.php 改成 shell.jpg 就能绕过前端检查，上传后如果服务器还允许直接访问该文件，攻击者就能执行任意代码。我曾经在一个政府网站上试过，上传目录甚至可以直接列出来，连文件名都不用猜。

还有一个常被忽视的地方：HTTP响应头。缺少 X-Frame-Options 意味着页面可能被嵌入恶意站点的iframe里，诱导用户点击。缺少 Content-Security-Policy 则让XSS攻击更容易得手。这些配置层面的问题，扫描器未必会报，但手动检查一遍花不了几分钟。

工具怎么用

Burp Suite 和 OWASP ZAP 是绕不开的工具。我个人更习惯用Burp的代理模式，把浏览器流量拦下来，逐个请求改参数重放。自动化扫描适合做初步筛查，但误报率高得离谱。有次扫描器报了一个“高危SQL注入”，我手动验证了半小时，发现只是参数类型不匹配导致的正常报错。工具给的是线索，判断还得靠人。

sqlmap 这类专用工具在确认注入点后很好用，但别一上来就对着生产环境跑。我朋友的站点那次，我是在本地搭了个镜像环境测的。直接在生产库上跑自动化注入，轻则锁表，重则数据丢失，这责任担不起。

写完报告之后

检测只是第一步。把漏洞整理成报告时，我习惯按利用难度和影响范围排序。一个能直接拿数据库权限的注入漏洞，优先级远高于一个需要用户交互才能触发的反射型XSS。修复建议要具体到代码层面，别只说“加强输入过滤”——告诉开发人员用参数化查询代替字符串拼接，用 htmlspecialchars() 处理输出，这才有用。

漏洞检测不是一劳永逸的事。今天修好的注入点，明天新加的功能可能又引入新的问题。定期扫一遍，比出了事再补救强得多。