去年有个朋友找我，何查说他的程序WordPress站点被挂马了，首页被跳转到博彩网站。漏洞我问他上次更新插件是何查什么时候，他想了半天说“记不清了”。程序登后台一看，漏洞WooCommerce版本还停留在两年前——那个版本有个已知的何查SQL注入漏洞，CVE编号我记不清了，程序但利用代码在GitHub上随便搜就能找到。漏洞这就是何查最典型的Web漏洞场景：不是被高级APT盯上，而是程序自己把门敞着。

查Web程序漏洞这件事，漏洞拆开来看就三个层面：代码本身、何查运行环境、程序配置。漏洞代码漏洞靠工具扫，环境漏洞靠版本比对，配置问题靠人眼加经验。

自动化扫描：别只装一个工具就完事

很多人装个AWVS或者Xray跑一遍，看到没有高危就放心了。这跟体检只量身高一样不靠谱。每个扫描器的Payload库和检测逻辑不同，同一个站点用不同工具扫出来的结果可能差出一倍。我的习惯是至少跑三个：

• Nikto——老牌但不过时，专门查Web服务器层面的问题，比如默认文件、危险HTTP方法、过时的CGI。它跑得快，输出有点噪音，但经常能发现你没想到的东西。
• nuclei——ProjectDiscovery出的，基于YAML模板。社区模板更新极快，新CVE出来一两天就有检测模板。适合批量扫已知漏洞。
• Burp Suite社区版——主动扫描功能有限，但手动爬站配合被动扫描，能抓到很多自动化工具漏掉的逻辑问题。比如某个API接口返回了不该返回的用户数据。

扫描之前记得确认你有授权。没授权扫别人的站，在大多数司法管辖区都是违法行为，别拿“我只是测试”当借口。

手动检查：扫描器不会告诉你的那些事

工具能查出SQL注入、XSS这些模式化的东西。但下面这些，基本靠人：

目录遍历和敏感文件暴露。试试访问 /.git/config、/.env、/backup.zip、/phpinfo.php。我见过一个电商站，/.env 直接能下载，数据库密码、Redis密码、支付网关密钥全在里面。扫描器不一定报，因为返回200不代表内容敏感——但你知道那意味着什么。

认证和会话管理。登录后把Cookie里的session token复制出来，用另一台机器带着这个token访问，看能不能直接进。再看看token有没有设置HttpOnly、Secure、SameSite。很多站点的session token就是用户ID的base64编码，改一个字符就能变成别人的身份。

业务逻辑漏洞。这个最容易被忽略。比如密码重置功能，请求里带用户ID，你把ID改成别人的，看能不能重置别人的密码。再比如优惠券，能不能重复使用、能不能篡改折扣金额。扫描器对这类问题基本无能为力，因为它不理解你的业务规则。

依赖和版本：供应链是重灾区

现代Web应用一半以上的代码来自第三方库和框架。Log4j、Spring4Shell、Fastjson这些事件都说明一个问题：你写的代码没问题，但你用的东西有问题。

查依赖漏洞，Java项目用 OWASP Dependency-Check，Node.js项目用 npm audit，Python用 pip-audit。前端框架看 package-lock.json 里的版本，对照CVE数据库。别嫌麻烦，一个过时的jQuery版本可能就带着已知的XSS漏洞。

运行环境同样重要。Nginx、Apache、Tomcat、PHP、数据库，每个都有版本对应的CVE。用 nmap -sV 或者 whatweb 先识别版本，再去NVD或者CVE Details查。我一般直接搜“组件名 + CVE + 当前版本号”，比翻数据库快。

配置问题：最容易被低估的一环

代码写得再安全，配置错了全白搭。几个高频问题：

• 目录列表没关，/uploads/ 下面所有文件都能列出来。
• CORS设置成 Access-Control-Allow-Origin: * 还带 Allow-Credentials: true，等于把API敞开给任何网站。
• 错误页面返回完整堆栈信息，数据库表名、文件路径全暴露。
• 默认管理后台路径没改，/admin、/manager/html 直接能访问登录页。

这些用 curl -I 看响应头、浏览器开发者工具看请求响应就能查。不需要多高深的技术，需要的是耐心和细心。

最后说一句：查漏洞不是一次性任务。今天扫完没漏洞，明天新CVE公布，你的站可能就中招了。把扫描和依赖检查放进CI/CD流程里，每次部署自动跑一遍，比每季度人工扫一次靠谱得多。