某天深夜，统存安全运维群里有人甩出一张截图：某政府网站的未授问漏druid监控页面赫然在目，SQL执行记录、权访Session ID、统存URI访问清单全裸奔在公网。未授问漏管理员一脸茫然——"我们没部署过这个组件啊？权访" 查了半天才发现，某业务系统引用的统存第三方jar包自带druid，默认配置没关监控页。未授问漏

这场景太常见了。权访Druid作为阿里开源的统存数据库连接池组件，几乎成了Java后端标配。未授问漏但很多人不知道，权访它自带的统存statViewServlet默认开启，且不校验访问权限。未授问漏只要在web.xml里配置了servlet映射，权访又没加登录过滤器，任何人都能通过/druid/index.html直接打开监控台。

漏洞的杀伤力不在页面本身，而在数据泄露的深度。点开"SQL监控"标签，能看到每一条执行过的SQL语句，包括参数值。某电商平台被拖库前，攻击者就是先摸到druid监控，分析出后台管理员的查询习惯，顺藤摸瓜找到数据库账号。更阴险的是"Session监控"——活跃用户的session ID直接暴露，配合其他漏洞就能伪造身份登录。

我做过一次测试，扫描某市教育网段，192个IP里有17个开放druid接口，其中9个能直接看到数据库连接信息。有个学校的系统甚至把数据库密码明文写在连接URL里，监控页面右下角"连接池配置"一览无余。这不是个别现象，金融、医疗、政务系统里都有中招的。

为什么默认配置这么危险？因为druid的文档里写了"建议生产环境关闭"，但很多开发同学图方便，直接抄demo配置就上线。更麻烦的是，有些框架（比如早期版本的renren-security）把druid监控页集成在后台管理里，以为登录了后台就能看，结果把监控servlet暴露在公网，后台登录形同虚设。

修复其实不难。最彻底的办法是删除web.xml里对statViewServlet的映射；如果业务必须用监控功能，就设置loginUsername和loginPassword，或者用Spring Security加一层拦截。但最扎心的是，很多系统根本找不到web.xml——Spring Boot项目用内嵌Tomcat，配置全在application.yml里，很多人不知道druid的stat-view-servlet默认是开启的。

还有个容易被忽略的点：即使你关闭了监控页，druid的WebStatFilter如果配置了principalSessionName，依然会通过Cookie追踪用户，某些版本存在反射型XSS。所以升级到最新版（1.2.20+）也是必须的，老版本1.1.10之类的漏洞一堆。

说到底，这漏洞属于"配置失误型"漏洞，和开发者的安全意识强相关。我见过最离谱的案例，某公司把druid监控当成"内部工具"放在公网，还特意做了内嵌页面，觉得没人知道路径就安全。结果扫描器几秒钟就发现，连字典都不用跑。

别迷信"没人会发现"。攻击者的扫描工具里，druid的路径早就是必测项了，和phpmyadmin、jenkins一个待遇。如果你不确定自己系统有没有这个问题，直接访问 /druid/index.html 试试——如果弹出登录框，说明还有救；如果直接显示表格，赶紧去改配置。趁还没出事，把该关的关掉，该加认证的加上，别等数据泄露了才拍大腿。