网站漏洞检查

上个月帮一个做跨境电商的网站朋友看他的独立站，刚打开后台我就愣住了——数据库配置文件直接暴露在Web根目录下，漏洞文件名还叫db_config.php.bak。检查我问他这个文件放了多久，网站他说“建站时就搁那儿了，漏洞一直没动过”。检查三分钟之后，网站我用浏览器直接下载了这个文件，漏洞里面明文写着数据库账号和密码。检查这不是网站段子，是漏洞我今年遇到的第四个同类案例。

很多人以为网站漏洞检查就是检查装个安全插件、扫一遍端口完事。网站真不是漏洞。漏洞这东西，检查七成以上出在“人觉得没问题”的地方。比如那个.bak备份文件，扫描器不一定报，因为它不算传统意义上的漏洞——它就是个文件。但攻击者根本不需要扫描器，他们用Google搜site:example.com ext:bak就能批量捞。这叫“信息泄露”，比SQL注入还常见，还容易被忽略。

我习惯把检查分成两条线走。一条是“机器能扫的”，一条是“机器扫不出来的”。

机器那条线，用nmap看端口，用nikto扫常见CGI问题，用sqlmap试注入点。这些工具跑一遍，能筛出三成左右的低级问题。但别全信它们。有次nikto报了个/admin/目录存在，我手动访问发现是403，再试/admin/加个..;/就进去了——Tomcat的路径解析漏洞，工具没报，因为它的规则库没覆盖这个变体。

机器扫不出来的那部分，得靠人蹲在浏览器里一点点试。比如登录框，输入' or 1=1--看报不报错，这是基础。更隐蔽的是“逻辑漏洞”：把商品ID从1001改成1002，看能不能看到别人的订单；把价格参数从99改成0.01，看后端有没有二次校验。我见过一个商城，前端JS校验价格，后端直接拿POST里的price入库。改个数字，一块钱买iPhone。

文件上传也是重灾区。有个客户做图片社交，上传接口只检查了Content-Type。我把shell.php改名成shell.jpg，抓包把Content-Type改成image/jpeg，传上去之后直接访问/uploads/shell.jpg——服务器当PHP执行了。他后来跟我说，服务器上已经被种了挖矿脚本，CPU天天跑满。

再说个细节：检查的时候别只看主站。api.example.com、m.example.com、test.example.com，这些子域名经常是“忘了关”的测试环境。我扫过一个test.开头的子域，里面是半年前的代码，数据库连接用的还是内网地址，但phpinfo()没删，直接暴露了绝对路径和所有环境变量。攻击者拿到这些，就能精准构造本地文件包含。

最后说个反直觉的：漏洞检查不是“找得越多越好”。有次我列了二十几个问题给一个客户，他直接懵了，不知道先修哪个。后来我按“能被利用的”和“暂时利用不了的”分了两堆，第一堆只有三个：备份文件、弱口令、上传绕过。他花了一下午修完，网站安全等级直接从“裸奔”变成“穿了件T恤”。剩下的那些，比如X-Powered-By暴露版本号，优先级排后面。

检查完记得写个清单，别光口头说。我习惯用表格：漏洞位置、复现步骤、风险等级、修复建议。给开发看的时候，直接贴curl命令和返回结果，比说“这里有问题”管用十倍。毕竟修漏洞的人，往往就是写漏洞的人。