利用AI模型对项目进行安全排查发现疑似漏洞

[Huiaei]

由于发生Alist项目被转卖以及可能投毒的怀疑产生的不安全和不信任，加之近期AI发展迅猛，所以尝试使用AI对项目进行了一次审查。但是由于本人代码水平以及相关开发知识水平都不高，无法验证其问题是否真实存在，所以采取此法进行分享给开发团队。

模型使用的是Google Gemini 2.5 Pro，使用Vscode的Roo Code插件，ffc14ea

生成的日志较长，以下内容由AI生成的总结报告：

---

OpenList 源代码安全分析报告

1. 概述

本次分析旨在识别 OpenList 项目中的潜在安全漏洞。通过对代码的静态审查，我们发现了多个严重等级的安全问题，这些问题可能导致未经授权的数据访问、账户接管和服务器受损。

2. 发现的漏洞

2.1 严重（Critical）：路径遍历漏洞

描述: 文件上传和文件操作功能中存在路径遍历漏洞。根本原因在于 pkg/utils/path.go 中的 JoinBasePath 函数未能正确地对用户提供的路径进行清理。该函数通过简单的字符串匹配来检测 ..，但这种检查可以被 URL 编码的字符（例如 %2e%2e 代表 ..）轻易绕过。
影响: 攻击者可以利用此漏洞上传文件到服务器上的任意位置，或者读取任意文件，这可能导致远程代码执行或敏感信息泄露。
受影响的文件:
pkg/utils/path.go:77（JoinBasePath 实现）
server/handles/fsup.go:40（文件上传处理调用了有漏洞的函数）
internal/model/user.go:141（用户模型调用了有漏洞的函数）
2.2 高危（High）：LDAP 注入

描述: 在 server/handles/ldap_login.go 的 LDAP 登录功能中，用户的输入被直接拼接到 LDAP 搜索过滤器中，而没有进行任何形式的转义或清理。
影响: 攻击者可以通过构造恶意的用户名来操纵 LDAP 查询，可能绕过身份验证、提取用户信息或导致拒绝服务。
受影响的文件:
server/handles/ldap_login.go:75（fmt.Sprintf(ldapUserSearchFilter, req.Username)）
2.3 高危（High）：不安全的密码存储

描述: 项目的密码哈希方案存在严重缺陷。它使用了一个快速哈希算法（两轮 SHA256），并且在第一轮哈希中使用了硬编码的、公开可见的静态盐。
影响: 这种方案无法有效抵御离线暴力破解或彩虹表攻击。如果数据库泄露，用户的密码将面临被破解的巨大风险。
受影响的文件:
internal/model/user.go:22（StaticHashSalt 的定义）
internal/model/user.go:144（StaticHash 的实现）
internal/model/user.go:152（TwoHashPwd 的实现）
2.4 高危（High）：LDAPS 连接中的不安全 TLS 配置

描述: 在建立 LDAPS 连接时，代码将 tls.Config 中的 InsecureSkipVerify 设置为 true，这完全禁用了对服务器证书的验证。
影响: 这使得应用程序容易受到中间人（MitM）攻击，攻击者可以冒充 LDAP 服务器来窃取用户凭据。
受影响的文件:
server/handles/ldap_login.go:153（ldap.DialTLS 的调用）
2.5 严重（Serious）：SSO 回调中的不安全 postMessage

描述: 在 SSO（单点登录）的回调处理中，代码使用 window.opener.postMessage 将会话令牌发送回父窗口，但将目标源（targetOrigin）设置为 "*"。
影响: 这意味着任何来源的页面都可以接收到该消息。如果用户被诱骗在一个恶意网站上执行登录流程，该恶意网站就可以窃取用户的会话令牌，从而劫持用户的会话。
受影响的文件:
server/handles/ssologin.go:246
server/handles/ssologin.go:273
server/handles/ssologin.go:411
server/handles/ssologin.go:439
3. 总结与建议

OpenList 项目存在多个严重的安全漏洞。我们强烈建议开发团队立即采取行动修复这些问题：

路径遍历: 使用基于文件系统路径解析的库来安全地处理路径，而不是依赖字符串操作。确保所有用户输入在用于文件操作前都经过严格的验证。
LDAP 注入: 使用参数化的 LDAP 查询或对所有用户输入进行严格的 LDAP 专有转义。
密码存储: 立即迁移到现代的、计算成本高昂的密码哈希算法，如 Argon2id。
不安全 TLS: 移除 InsecureSkipVerify: true，并确保应用程序正确验证服务器证书。
postMessage 漏洞: 在 postMessage 调用中始终指定确切的目标源，而不是使用通配符 *。

---

[jyxjjj]

2.3 请参阅 #32 (comment)

另，请提供SHA256被彩虹表的证明。

其他问题并非我们制作，我们也还没动到这些，目前仅根据项目一开始的代码审查进行回复：

认为即使存在也仅是属于漏洞而非刻意隐藏的原有后门。

我们会逐个进行讨论，如确认存在，将进行修复。

[jyxjjj]

2.4 2.5 并不认为是漏洞，因为要兼容所有用户，这是开源项目，但我们可能也会采取行动如提供填写自签名证书及填写目标域名的方式。

[Huiaei]

首先，很高兴开发团队对于安全问题的重视。

AI所提到的“漏洞报告”确实存在不严谨的地方，如 @jyxjjj 提到的SHA-256被暴力破解与彩虹表攻击的问题，再次询问AI，其回答也是说明可能性微乎其微。其他的问题可能也或多或少的经过了开发团队或者社区的讨论，被证实或者已经提出了解决方案。

回到这个讨论的目的，是利用AI对当前项目进行一次代码审查，以排除潜在可能的安全风险，是一次“突发奇想”。但是，也可能由于AI的不稳定或是模型可能出现的幻觉，可能对发现的问题无法详细的验证和论证漏洞的可能性。其中有太多的因素可能造成结果的变化，所以只是作为一个“提醒”来告知开发团队，不是对开发团队不信任或者是怀疑其能力水平，而是希望这个项目能更加的好。

之后可能还会再次的“突发奇想”来利用AI对项目进行审查，不过下次我应该会对结果进行一些验证以及尝试采用多个模型来消除单个模型的一些问题。问题验证这一块由于本人不是相关专业学科的人，所以可能只会进行一些简单的测试。

最后，感谢开发团队对于安全的重视。Openlist以及Alist毕竟现在的用户量很大，所以出现了问题受到影响的范围就越来越大了。