安全问题

报告安全问题

如果您认为您在 Symfony 中发现了安全问题，请不要使用 bug 跟踪器，也不要公开它。相反，所有安全问题都必须发送至 security [at] symfony.com。发送到此地址的电子邮件将转发到 Symfony 核心团队的私有邮件列表。

以下问题不被视为安全问题，应作为常规 bug 修复处理（如果您有任何疑问，请随时发送电子邮件给我们以进行确认）：

• 在调试工具中发现的任何安全问题，这些工具绝不能在生产环境中启用（包括 Web 分析器或在 APP_DEBUG 设置为 true 或 APP_ENV 设置为除 prod 之外的任何值时启用的任何内容）；
• 在为测试提供的类中发现的任何安全问题，这些类绝不应在生产环境中使用（例如名称中包含 Mock 的模拟类或 Test 命名空间中的类）；
• 任何可以归类为安全加固的修复，例如路由枚举、登录节流绕过、拒绝服务攻击、定时攻击或缺少 SensitiveParameter 属性。

在任何情况下，核心团队对哪些问题被视为安全漏洞拥有最终决定权。

安全漏洞赏金

Symfony 是一个开源项目，其中大部分工作由志愿者完成。我们感谢开发人员尝试查找 Symfony 中的安全问题并负责任地报告它们，但我们目前无法支付漏洞赏金。

解决流程

对于每份报告，我们首先尝试确认漏洞。确认后，核心团队将按照以下步骤制定解决方案：

1. 向报告者发送确认函；
2. 制定补丁；
3. 从 mitre.org 获取 CVE 标识符；

4. 为 Symfony 官方 博客 撰写关于该漏洞的安全公告。此帖子应包含以下信息：

   • 始终包含“安全发布”字符串的标题；
   • 漏洞描述；
   • 受影响的版本；
   • 可能的漏洞利用；
   • 如何修补/升级/绕过受影响的应用程序；
   • CVE 标识符；
   • 致谢。
5. 将补丁和公告发送给报告者以供审核；
6. 将补丁应用于所有维护的 Symfony 版本；
7. 为所有受影响的版本打包新版本；
8. 在 Symfony 官方 博客 上发布帖子（也必须将其添加到“`安全公告`_”类别）；
9. 更新由 FriendsOfPHP 组织维护的公共 安全公告数据库，该数据库由 check:security 命令 使用。

与下游开源项目协作

由于 Symfony 被许多大型开源项目使用，我们标准化了 Symfony 安全团队与下游项目在安全问题上的协作方式。流程如下：

1. 在 Symfony 安全团队确认安全问题后，它会立即向下游项目安全团队发送电子邮件，告知他们该问题；
2. Symfony 安全团队创建一个私有 Git 仓库，以方便就该问题进行协作，并向 Symfony 安全团队、受该问题影响的 Symfony 贡献者以及每个下游项目的一名代表授予对该仓库的访问权限；
3. 所有有权访问私有仓库的人员都通过拉取请求、代码审查和评论来协作解决问题；
4. 找到修复程序后，所有相关项目都会协作寻找联合发布的最佳日期（不能保证所有发布都会在同一时间，但我们将尽力使它们在同一时间左右发布）。当已知该问题未在野外被利用时，两周的时间被认为是合理的时间量。

参与此过程的下游项目列表保持尽可能小，以便更好地管理披露前机密信息的流动。因此，项目是否包含在内由 Symfony 安全团队自行决定。

截至今天，以下项目已验证此过程，并且是此过程中包含的下游项目的一部分：

• Drupal（发布通常在星期三进行）
• eZPublish

问题严重性

为了确定安全问题的严重性，我们会考虑任何潜在攻击的复杂性、漏洞的影响以及可能影响的项目数量。这个 15 分的总分随后会转换为以下级别：低、中、高、严重或特殊。

安全公告

查看 安全公告 博客类别，获取 Symfony 版本中修复的所有安全漏洞的列表，从 Symfony 1.0.0 开始。