开源项目new-api中敏感信息日志打印的安全隐患分析

背景介绍

在开源项目new-api的AWS Bedrock渠道实现中，开发人员发现了一个潜在的安全隐患——系统日志中直接打印了包含AWS访问密钥(Access Key)的明文敏感信息。这一问题出现在2025年4月被报告，并很快得到了修复。

问题详情

当系统通过AWS Bedrock渠道进行API调用时，调试日志中完整记录了包括以下敏感信息在内的渠道配置详情：

• AWS访问密钥ID(AKIATT开头)
• AWS秘密访问密钥(9f28D开头)
• AWS区域(us-east-1)

这些信息以明文形式出现在系统日志中，格式如下：

[SYS] 2025/04/25 - 15:38:56 | testing channel 1 with model claude-3-5-haiku-20241022 , info &{... AKIATTxxxxxxxxx|9f28Dxxxxxxxx|us-east-1 ...}

安全隐患分析

1. 密钥泄露风险：AWS访问密钥等同于云服务账户的"用户名+密码"，一旦泄露可能造成严重的安全事故。

2. 日志传播风险：系统日志通常会被收集到集中式日志系统，增加了密钥被不当访问的可能性。

3. 合规性问题：许多安全合规标准(如ISO27001、GDPR等)都明确要求不能记录敏感信息的明文。

4. 最小权限原则违反：日志中不应包含执行当前操作不需要的信息。

解决方案建议

1. 日志脱敏处理：对敏感字段进行部分隐藏(如只显示前几位字符)。

2. 结构化日志：将敏感信息单独处理，避免在常规日志中输出。

3. 环境区分：开发环境可以输出详细信息，生产环境则应严格过滤。

4. 安全审计：定期检查日志输出内容，确保没有新增的敏感信息泄露点。

最佳实践

1. 使用专门的密钥管理服务(如AWS Secrets Manager)来存储和访问密钥。

2. 实现自动化的日志敏感信息扫描机制。

3. 在代码审查阶段加入对日志输出的安全检查。

4. 为开发团队提供安全编码培训，提高安全意识。

总结

这个案例提醒我们，在开发过程中不仅要关注功能的实现，还需要时刻注意安全性问题。特别是在处理云服务凭证等敏感信息时，必须遵循安全最佳实践，避免因为日志记录不当导致的信息泄露风险。开源项目由于代码公开性，更需要注意这类问题的处理。