Jira API令牌在GitHub公开仓库泄露导致内部信息横向泄露风险

在GitHub浏览代码仓库时，偶然发现了一个项目。出于安全测试的习惯，我尝试搜索了一些敏感关键词，结果在一个Kotlin文件中发现了硬编码的Jira API令牌。

尽管这个代码仓库已经很长时间没有更新，我仍然决定尝试用这个令牌去调用Jira的API。

结果令人意外：API请求竟然成功了！我可以直接访问该Jira实例的issue数据。而在正常情况下，访问这个Jira域名理应被强制跳转到Atlassian的OAuth登录页面。

这表明企业开发人员将有效的Jira API令牌以明文形式写入了公开的GitHub仓库，导致任何人都能绕过正常的Web登录验证，直接访问内部Jira系统。

漏洞点分析

🔴 漏洞点 1：敏感凭证被硬编码并公开
在源码中直接发现了如下定义：

const val token = "██████"

🔴 漏洞点 2：Basic Authentication 方式仍被接受
通过该令牌发起API请求时，请求头中使用了Basic Auth：

Authorization: Basic ████████

这实际上是 Base64(username:APIToken) 的编码结果。

这说明了几个关键问题：

• Jira REST API 信任并使用这个令牌进行认证。
• 整个过程不需要浏览器会话Cookie，也不需要经过OAuth授权跳转。
• 攻击者借此完全绕过了Web应用层的登录验证。

🔴 漏洞点 3：令牌权限范围过大（高危）
成功访问的接口示例如下：

GET /rest/api/2/issue/67212

这意味着该令牌至少拥有 read:jira-work 权限，很可能还包含读取用户、项目、评论等更广泛的权限。利用此令牌，攻击者可以：

• 枚举所有issue及其详细信息。
• 获取内部项目结构和人员列表。
• 访问潜在的敏感沟通和附件。

这本质上构成了一次严重的横向信息泄露，内部工作数据完全暴露。此类问题在安全测试与渗透攻防领域是重点排查对象。

总结与反思

此次事件暴露了开发流程中的典型安全隐患：

1. 密钥管理缺失：生产环境凭证绝不应以硬编码形式存在于源码中，更不用说公开仓库。
2. 凭证生命周期管理不当：即使代码已归档，关联的API令牌若未及时撤销，风险依然存在。
3. 过度授权：为自动化脚本或集成服务分配的令牌应遵循最小权限原则，避免使用拥有过大访问范围的“万能”令牌。

对于开发者而言，务必使用环境变量或安全的密钥管理服务来存储敏感信息，并定期审计和轮换密钥。安全建设是一个持续的过程，对这类潜在风险保持警惕至关重要。更多关于开发安全实践的讨论，欢迎在云栈社区与大家交流。

参考链接
https://hackerone.com/reports/1785145