渗透测试时发现 druid 信息页面泄露

凌晨两点，渗透客户的测试生产环境告警日志里滚过一串奇怪的路径请求。我点开WAF记录，现d信息泄露看到有人对着`/druid/index.html`猛刷了十几遍。页面这名字太扎眼了——Druid连接池监控页，渗透默认不设防的测试话，等于把数据库的现d信息泄露体检报告直接挂在大街上。

那次测试目标是页面个金融系统，资产测绘阶段扫到8080端口开了个管理台。渗透本来以为是测试Tomcat默认页，结果curl一探，现d信息泄露返回的页面HTML里明晃晃写着`DruidStatViewServlet`。心里咯噔一下，渗透赶紧在浏览器里敲完整路径。测试页面秒开，现d信息泄露蓝白配色的监控面板上，SQL执行次数、慢查询列表、甚至最后一条JDBC连接串全摊在眼前。

最要命的是"数据源"标签页。点进去，连接池的URL、用户名、密码加密后的密文整整齐齐列着。虽然密码是密文，但Druid的加密算法是公开的，配合页面泄露的`publicKey`，用工具跑几分钟就能还原出明文。那一刻我后背发凉——这系统里跑着支付流水，可攻击者不需要打什么高深的漏洞，打开一个页面就能拿到数据库钥匙。

这类泄露在实战里太常见了。很多开发图省事，直接在`web.xml`里把`StatViewServlet`的`loginUsername`和`loginPassword`留空。或者更隐蔽些，虽然设了密码，但把监控页挂在Nginx根路径下，没做IP白名单。上个月测一个政务平台更离谱，Druid页面不仅没锁，还嵌套在iframe里被主站直接引用，等于任何访客都能看到内网数据库的实时状态。

修复其实不难，但总有人嫌麻烦。我见过最蠢的补救是只删了页面上的"数据源"菜单，结果直接访问`/druid/datasource.json`照样能拉出全部信息——前端隐藏不等于后端禁用。正确做法是三步走：第一，给`StatViewServlet`设置强口令，别用`admin/123456`这种；第二，把监控页的访问权限收进内网，或者至少绑定VPN；第三，如果业务确实不需要，干脆在配置里把`stat-view-servlet`的`enabled`设为`false`，眼不见为净。

那次测试结束后，我在报告里把Druid泄露标成高危。客户还觉得小题大做，直到我演示了用泄露的密文配合工具还原出测试库密码，他们才变了脸色。后来听他们运维说，修复时发现生产库的Druid密码跟测试库一模一样——这种连锁反应才是真正的雷。

说到底，Druid监控页泄露不算多高深的洞，但它像汽车仪表盘没贴膜——你不怕被人看见时速，可要是油箱剩余量和刹车片磨损度都暴露了，懂行的人就能算出你什么时候会抛锚。渗透测试的价值，不就在于把这些藏在犄角旮旯的“小疏忽”翻出来，逼着人正视吗？

很赞哦!（1）