白盒测试遇上Mongo未授权，这坑我替你踩过了！
哎,兄弟们，今天咱们不聊虚的，就聊聊我最近在攻防演练里踩的一个大坑——白盒测试Mongo未授权访问，说真的，这玩意儿以前我只在应急响应报告里看过，觉得不就是改个配置嘛，有啥难的？结果真到自己动手去测，才发现里面的水比想象中深多了，气得我差点把键盘砸了！
事情是这样的,当时甲方爸爸丢过来一套系统源码，要求做白盒审计，我扫了一圈，发现是个典型的Java Web应用，Spring Boot框架，Redis、MySQL啥的都挺正常，但当我打开application.yml配置文件的那一刻，我愣住了——spring.data.mongodb.uri: mongodb://admin:password@192.168.1.100:27017/authdb？嗯，看这玩意儿，密码是明文？这还不算完，我顺着代码往下翻，在某个业务逻辑里直接用了MongoTemplate去查询用户信息，连个参数校验都没有。
我的天呐,白盒测试的乐趣就在这儿，你能肉眼看到漏洞是怎么被写出来的！这要是黑盒，估计得费老鼻子劲去爆破或者跳板才能摸到MongoDB的端口，但在白盒视角下，一切细节都赤裸裸地摆在那儿，就跟看自己家保险柜密码写在便利贴上一样，这心情，那叫一个“复杂”啊！
重点来了,光找到配置有啥用？咱们得验证它到底能不能连上啊！于是我在本地起了个环境，先验证了版本信息，然后尝试用那个账号密码去登录，结果你猜怎么着？Mongo未授权访问这个经典老番，居然还真让我给复现了！虽然配置文件里写了认证数据库，但执行db.auth()之后，我惊讶地发现，那个账号居然有clusterAdmin的权限！这不是直接把钥匙和门都送人了吗？我当时就“我嘞个豆”一声，这也太不拿安全当回事了吧？！
接下来的操作,估计大家都猜到了，我通过这个高权限连接，直接show dbs，然后看到了user_db，接着就去查里面的用户表，好家伙，里面的密码哈希、手机号、身份证号码全是明文存储！我甚至可以用这个超级管理员权限去往roles表里插一条新管理员记录，为后续持久化做铺垫，这种感觉，怎么说呢，就像你本来只想测试一下门锁是否灵活，结果直接把整个保险柜搬到手了，既刺激又有点后怕。
说到这儿,我得给各位搞安全的同行提个醒。白盒测试Mongo未授权，重点在于“未”字，也就是说，不仅要看代码里是否指定了authorization参数，还要看服务启动时是否真的启用了认证，我这次就差点被那个authdb参数给骗了，以为认证是开着的，结果再往下扒拉，发现启动脚本里压根没加--auth参数，哈哈，这找谁说理去？这坑，你们千万别再踩了！
咱们总结一下,遇到MongoDB，无论是黑盒还是白盒，先别急着高兴，得从端口暴露范围、配置文件是否泄露、连接串是否带高权限账号、以及启动参数是否启用认证这四个维度去排查，只有把这些都摸透了，才算真正搞懂了白盒测试里的精髓，唉，总之这次经历让我对Mongo的认知又上了一个台阶，代价是熬了个大夜，但值得！
好了,我的吐血经验就分享到这儿。
学习网络安全可以加QQ：747884181（记得备注来源哦！）
咱们下篇文章见,拜了个拜！
