Skip to main content

🛡️ 安全政策

Sponsored by Open WebUI Inc.
Open WebUI Inc.

We are hiring! Shape the way humanity engages with intelligence.

在 Open WebUI，保护用户数据的安全性和机密性是我们的首要任务。我们的技术架构和开发流程旨在最大限度地减少漏洞，并维护利益相关者对我们的信任。定期的评估、代码库审查以及对最佳实践方法的系统性采纳，确保了安全性始终贯穿于我们项目生命周期的核心。

我们结合使用自动化和手动技术来应对不断演变的威胁，并持续改进我们的方法，包括计划集成先进的静态和依赖项分析工具。我们的重点始终是主动风险管理和对报告漏洞的负责任处理。

支持的版本​

版本是否支持
main✅
其他版本❌

安全漏洞报告的地点与方式​

info

Open WebUI 社区的繁荣离不开像您这样深切关注软件安全的人。

为了确保您的发现能真正帮助保护用户并得到迅速处理，请仅通过我们的官方 GitHub 安全页面提交所有安全漏洞报告。任何其他网站、服务或所谓的“赏金”平台均不隶属于我们，您的重要工作将无法传达给能够解决问题的人员。

我们知道那些做出巨大承诺的平台可能很有吸引力，但只有 GitHub 才能让您直接联系到 Open WebUI 的安全维护者。让我们确保您的警惕性能真正惠及社区，请在真正发挥作用的地方（即此处）提交报告。

Open WebUI 的所有安全漏洞必须专门通过我们的官方 GitHub 仓库报告：https://github.com/open-webui/open-webui/security。

我们致力于通过确保所有安全漏洞报告均由我们的官方 GitHub 平台独家管理，来维护一个安全的环境。通过在 GitHub 上集中处理披露信息，我们保证每份报告都由项目维护者以透明、高效且机密的方式处理。这种方法使我们能够为贡献者和用户提供最高水平的可见性、问责制，并确保所有与安全相关的沟通和解决方案都得到详尽记录和可靠管理。通过 GitHub 之外的任何平台、渠道或第三方服务提交的报告无法纳入我们的官方安全工作流，因此可能无法为 Open WebUI 的安全做出贡献。

为什么仅限 GitHub？​

我们坚持单一、集中报告机制的承诺根植于技术严谨性和伦理责任：

  • 完整性与可追溯性： 仅通过 GitHub 管理报告可确保每个问题都在开源生态系统内处理，社区可以验证处理过程、结果以及贡献者的责任。
  • 用户安全： 其他声称促进漏洞披露、提供奖励或赏金计划的网站均不隶属于 Open WebUI。向此类平台提交漏洞不仅无法使项目更安全，还可能无意中使敏感细节面临被滥用或未经授权披露的风险。
  • 保护社区： 当信息绕过我们的集中安全工作流时，项目不仅更容易受到未修复漏洞的影响，也更容易受到误导性或剥削性做法的传播。尽管外部网站声称充当中介或支付赏金，但这些实体对用户不提供任何保证，并可能在激励的幌子下鼓励可疑或不安全的行为。最终，只有通过我们的 GitHub 进行披露，才能确保您的专业知识按预期惠及整个生态系统。

报告准则​

您可以在此处找到安全准则的最新版本。

为了确保提交的报告具有建设性和可操作性，并能真正提高安全性，所有提交内容必须满足以下要求：

  1. 报告必须是一个漏洞：安全漏洞是一个可利用的弱点，系统表现出非预期行为，允许攻击者绕过安全控制、获得未经授权的访问、执行任意代码或提升权限。配置选项、缺失的功能以及预期的协议行为不属于漏洞。

  2. 禁止含糊不清的报告：诸如“我发现了一个漏洞”但没有任何细节的提交将被视为垃圾信息且不予受理。

  3. 需要深入理解：报告必须反映出对代码库的清晰理解，并提供有关漏洞的具体细节，包括受影响的组件和潜在影响。

  4. 必须提供概念验证 (PoC)：每次提交必须包含一份记录详尽的概念验证，以演示该漏洞。PoC 必须展示跨越了哪个安全边界（机密性、完整性、可用性、真实性、不可抵赖性）、该漏洞是如何被滥用的，以及攻击者现在可以执行哪些操作。有效的 PoC 包括带有精确命令的分步复现指令、带有详细执行指令的完整漏洞利用代码，或演示漏洞利用的截图/视频（作为书面步骤的补充）。如果涉及机密性问题，鼓励报告者创建仓库的私有分支并向维护者共享访问权限。缺乏有效证据的报告可能会被忽略。如果我们无法使用您的 PoC 复现漏洞利用，我们会通知您，但如果多次无法复现，报告可能会被关闭。

  5. 必须提交补丁或可操作的修复计划：除 PoC 外，报告者必须提供补丁或修复已识别漏洞的可操作步骤。这有助于我们快速评估并实施修复，并展示对项目持续稳健性的承诺。

  6. 简化的合并流程：当漏洞报告符合上述标准时，我们可以考虑立即合并提供的补丁，类似于常规的拉取请求（Pull Request）。结构良好且详尽的提交将加快我们增强安全性的进程。

  7. 默认配置测试：所有漏洞报告必须使用 Open WebUI 的开箱即用默认配置进行测试和复现。仅在显式削弱安全设置时才出现的漏洞声明可能会被忽略。但是，如果您认为发现了一个影响默认配置的安全问题，代表了对预期安全控制的真实绕过，或者虽然仅在非默认配置下工作但该配置很可能被生产部署使用，那么我们绝对希望了解它。此政策旨在过滤配置问题和部署问题，而非阻止正当的安全研究。

  8. 需要理解威胁模型：报告必须展示对 Open WebUI 自托管、已身份验证、基于角色的访问控制架构的理解。如果将 Open WebUI 与具有根本不同安全模型的服务进行比较，而不承认架构差异，可能会导致报告被拒绝。

  9. CVSS 评分准确性：如果您在报告中包含 CVSS 评分，它必须根据 CVSS 方法论准确反映漏洞。常见错误包括：在需要身份验证时评级为 PR:N（无）、对假设的攻击链而非实际漏洞进行评分，或在没有证据的情况下夸大严重性。我们将调整不准确的 CVSS 评分。故意夸大的评分可能导致报告被拒绝。如果您引用其他 CVE 来支持您的报告，请确保它们在漏洞类型、威胁模型和攻击向量方面具有真实的可比性。引用来自不同产品类别、不同漏洞等级或不同部署模型的 CVE 将使我们怀疑您的报告中使用了 AI。

  10. 管理员操作不在讨论范围内：要求管理员主动执行不安全操作的漏洞不被视为有效漏洞。管理员拥有完全的系统控制权，并被预期理解其操作和配置的安全含义。这包括但不限于添加恶意的外部服务器（模型、工具、Webhook）、将不可信的代码粘贴到函数/工具中，或故意削弱安全设置。需要管理员疏忽或对管理员进行社会工程学的报告可能会被拒绝。但是，如果您认为发现了一个影响管理员且并非由管理员疏忽或故意恶意操作引起的漏洞，那么我们绝对希望了解它。此政策旨在过滤针对管理员的社会工程学攻击及类似的恶意操作，而非阻止正当的安全研究。

  11. AI 报告透明度：由于 AI 辅助的漏洞报告极端激增，您必须披露是否以任何身份使用了 AI——无论是用于编写报告、生成 PoC 还是识别漏洞。AI 辅助的漏洞报告默认不会被拒绝。但是，如果我们怀疑您使用了 AI 但未向我们披露，我们将提出严厉的后续问题以验证您对所报告漏洞及 Open WebUI 本身的理解。如果我们怀疑您使用了 AI 但未披露，且您的报告最终无效、不属于漏洞或无法复现，那么您可能会被禁止提交未来的漏洞。这一措施是必要的，因为显然由 AI 编写的漏洞报告极端增加，其中绝大多数并非漏洞、是错误的配置而非真实的漏洞、未提供 PoC、违反了此处概述的规则、明显缺乏对 Open WebUI 的理解、编写了信息冲突的注释或使用了逻辑不通的论据。

不符合要求的提交将被关闭，重复的极端违规者可能会被封禁。我们的目标是培育一个建设性的报告环境，让高质量的提交能够促进所有用户的更好安全。不仅识别出漏洞而且还提供稳健、随时可合并的修复方案的贡献者，有助于加速我们的响应并增强社区。

如果您觉得由于漏洞的具体原因无法遵循所有列出的要求，仍请进行报告——无论如何我们都会检查每份报告。

对于非漏洞相关的安全疑虑​

如果您的疑虑不符合上述漏洞要求，不属于漏洞，但仍与安全问题相关，请改用以下渠道：

非漏洞但仍与安全相关的疑虑示例包括：关于更好默认配置值的建议、安全加固建议、部署最佳实践指导、不清晰的配置说明、对额外安全文档的需求、可选安全增强（2FA、审计日志等）的功能请求，以及关于生产部署的一般安全问题。请针对您的具体问题使用适当的渠道。

产品安全流程​

  • 对我们的架构和管道进行内部和定期的外部审查
  • 针对前端和后端进行自动化和手动测试
  • 作为持续开发的一部分，进行主动风险管理和代码审查
  • 持续改进并集成用于静态/动态分析的高级工具

如果您有紧急且可操作的安全疑虑，请在我们的安全公告门户或 Issue 追踪器中创建报告。