kali扫描获取web隐藏页面

凌晨两点，扫描我盯着终端里滚动的藏页字符流，第37次按下了回车。扫描目标站点的藏页robots.txt早就看过了，干干净净，扫描什么都没藏。藏页可总觉得不对劲——一个政府级的扫描门户站，后台入口怎么会这么安静？藏页

Kali里躺着几十款扫描工具，真正好用的扫描就那几个。我习惯先用nmap扫端口，藏页再上gobuster跑目录。扫描这次也一样，藏页线程调到50，扫描字典用的藏页dirbuster的medium列表。屏幕上开始刷出200、扫描301、403的状态码，大多数是没用的静态资源。直到一行输出让我停住了手指：/console/，状态码200，响应字节数却只有342。

这数字太小了。正常页面怎么也有几KB。我curl了一下，返回的是一段JS重定向代码，指向/console/login.php。有意思，真正的登录页藏得还挺深。不过gobuster已经把这层皮扒下来了，接下来就是看它里面到底有什么。

换用wfuzz跑参数，同时挂着burp抓包。登录框是标准的POST表单，用户名和密码字段都没做加密。我试了试SQL注入，单引号直接报错，数据库类型暴露了——MySQL 5.7。这版本不算老，但运维肯定没做参数化查询。时间盲注可行，不过太慢了。我翻了翻字典，找到了一个叫"admin"的弱口令列表，里面有些奇葩密码，比如"admin123"、"password"这种。

结果第三行就进去了。密码是P@ssw0rd2023。这让我有点失望，又有点庆幸。失望的是对方连密码策略都没做强制，庆幸的是不用再耗下去了。进去之后是个文件管理面板，能浏览服务器上的目录。我顺着路径往上翻，在/var/www/html/backup/里发现了一个压缩包，名字叫site_old.tar.gz，修改日期是去年年底。

下载下来解压，里面是整套站点的旧版本源码。数据库配置文件里躺着明文密码，连salt都没加。更关键的是，压缩包里有个.git目录，说明开发人员当时没清理版本控制历史。我翻了翻log，发现一条提交记录写着"fix upload vuln"，点开diff一看，原来之前的上传接口只检查了文件扩展名的后缀，没验证MIME类型。虽然这个漏洞已经被修了，但备份文件里还留着旧代码——只要我把它重新部署到一个测试环境，就能复现整个攻击链。

整个过程花了不到四十分钟。说实话，这种隐藏页面根本算不上什么高深技术，纯粹是信息收集做得到不到位的问题。很多管理员以为把后台路径改得隐蔽点就安全了，却忽略了扫描器会遍历所有可能的目录名。真正的防护不是藏，是堵。你藏得再深，只要字典够大，总会被撞出来。

后来我把那个备份文件打包留了证据，然后通过CNVD提交了漏洞报告。三天后收到回复，说已经通知厂商修复了。我再去访问那个/console/路径，返回404了。挺好，至少他们知道把备份文件删了。但谁知道还有没有别的备份散落在哪个角落里呢？