数据库安全自查清单：你的Redis/MongoDB真的防住注入攻击了吗？
数据库安全自查清单：你的Redis/MongoDB真的防住注入攻击了吗？
在数字化转型浪潮中，NoSQL数据库凭借其灵活性和高性能成为众多企业的首选。但当我们享受Redis闪电般的读写速度、MongoDB文档模型的便利时，是否认真审视过这些数据库暴露的安全风险？去年某电商平台因MongoDB未授权访问导致百万用户数据泄露，今年初某社交应用又因Redis注入漏洞被攻陷——这些事件不断提醒我们：NoSQL的安全防护绝不能成为事后补救项。
本文将采用渗透测试工程师的视角，带你逐层拆解Redis和MongoDB最常见的安全盲区。不同于传统的防御理论堆砌，我们采用实战问答形式设计自查项，每个问题都对应着黑客真实攻击路径。只需15分钟完成这份清单，就能定位你的数据库系统中那些正在"裸奔"的危险配置。
1. 访问控制：你的数据库大门真的上锁了吗？
1.1 认证机制是否形同虚设？
Redis的默认配置中没有密码保护，这是最容易被利用的致命弱点。检查你的redis.conf文件中是否存在这样的危险配置：
# 错误示范 - 等同于敞开大门 protected-mode no requirepass ""而MongoDB在3.6版本前的默认配置同样允许匿名访问。执行以下命令验证认证状态：
// MongoDB认证检查 db.runCommand({connectionStatus: 1}).authInfo.authenticatedUsers必须立即实施的修复方案：
- Redis启用密码并设置强密码策略（长度≥16位，含特殊字符）
- MongoDB启用SCRAM-SHA-256认证并关闭localhost例外
- 定期轮换密码（建议每90天）
1.2 网络暴露面是否过大？
通过nmap快速检测数据库的暴露情况：
nmap -p 27017,6379 --script mongodb*,redis* 你的服务器IP常见危险结果包括：
| 端口 | 风险项 | 危险等级 |
|---|---|---|
| 6379 | Redis未绑定特定IP | 高危 |
| 27017 | MongoDB开启telnet端口 | 严重 |
注意：生产环境数据库绝不应该监听0.0.0.0，必须配置防火墙规则限制访问源IP。
2. 注入防御：NoSQL真的免疫注入吗？
2.1 MongoDB查询注入检测
虽然MongoDB使用BSON格式理论上能预防SQL注入，但错误的使用方式仍会导致注入漏洞。检查你的代码是否存在这种危险模式：
// 危险! 用户输入直接拼接 db.users.find({$where: "this.role == '" + userInput + "'"}) // 安全参数化查询 db.users.find({role: {$eq: userInput}})特殊字符测试用例：
' || '1'=='1 {$ne: null} {"$gt": ""}2.2 Redis命令注入实战
Redis的EVAL命令如果处理不当会成为注入入口。尝试这个检测payload：
-- 测试Lua脚本注入 eval 'return {tonumber(ARGV[1])}' 0 "1; redis.call('config','set','dir','/tmp')"防御关键点：
- 永远不用拼接方式构造Redis命令
- 对Lua脚本进行沙箱隔离
- 禁用危险命令（如下表）
| 需禁用命令 | 替代方案 |
|---|---|
| FLUSHALL | 重命名或禁用 |
| CONFIG | 使用rename-command配置 |
| KEYS | 使用SCAN替代 |
3. 数据安全：敏感信息是否在裸奔？
3.1 加密存储检查清单
执行以下操作验证数据加密状态：
// MongoDB加密检查 db.getCollectionInfos().forEach(function(c) { printjson(db[c.name].findOne({}, {_id:0})) })高风险特征包括：
- 明文存储密码哈希（应使用bcrypt/scrypt）
- 信用卡号完整存储（应token化）
- 个人身份信息未脱敏
3.2 内存数据防护策略
Redis作为内存数据库需要特别防护：
- 开启AOF持久化并设置fsync策略
- 敏感数据使用
--save ""禁用快照 - 定期执行内存分析：
MEMORY USAGE key_name MEMORY STATS4. 运维监控：你的防御体系有感知能力吗？
4.1 审计日志配置检测
MongoDB企业版提供完善的审计功能，社区版可通过以下方式弥补：
// 创建简易操作日志 db.createCollection("operation_log", { capped: true, size: 10000000 })Redis则需要借助外部工具如ELK实现：
# 监控Redis命令 redis-cli monitor | grep -E "config|flush|auth"4.2 实时告警阈值设置
建议配置的监控指标：
| 指标项 | 危险阈值 | 应对措施 |
|---|---|---|
| 失败认证次数/分钟 | >5次 | 触发IP封禁 |
| 大key删除操作 | 任意次数 | 立即短信通知 |
| 内存使用率 | >80% | 自动扩展并告警 |
最后分享一个真实案例：某金融APP因为忽略Redis的ACL配置，攻击者通过注入漏洞获取了所有会话令牌。我们在渗透测试中发现这个问题时，他们的第一反应是"Redis也需要防注入？"。现在，你的数据库还会给黑客留下这样的惊喜吗？