OWASP 漏洞 ID：WSTG-IDNT-04
重现步骤：
漏洞描述（来自 OWASP）：
通过与应用程序的身份验证机制进行交互，可以收集一组有效的用户名。此测试对于暴力破解测试很有用，在该测试中，测试人员会验证给定有效用户名是否可以找到相应的密码。
通常，Web 应用程序会显示用户名是否存在于系统中，这可能是由于配置错误或设计决策。例如，有时当我们提交错误的凭据时，我们会收到一条消息，说明用户名存在于系统中或提供的密码错误。攻击者可以利用获取的信息来获取系统上的用户列表。这些信息可用于攻击 Web 应用程序，例如，通过暴力破解或默认用户名和密码攻击。
建议修复：
启用管理员 - 设置 - 登录 - 隐藏电子邮件地址已被使用
隐藏电子邮件地址已被使用
在注册或忘记密码流程中，不要告知用户某个电子邮件地址已存在。在“忘记密码”请求中需要完整的电子邮件地址。
另请参阅 Different password reset for wrong username/email （2014 ;)）
编辑 @JammyDodger 快了 40 秒
Around the web, this has come up a few times before. I think one of the other important points is that we have rate-limiting on trying to log in:
感谢你们两位。我在 meta.discourse.org 上偶然发现了这个 bug，并且不知道有这个设置，但很高兴知道修复程序已经编写完成，并且补丁应该非常直接。为了满足 OWASP 的最佳实践，该设置应始终启用。我不知道任何管理员为什么会希望禁用此设置，因为这样做会带来完全不必要的安全和隐私漏洞，并且明确违反行业最佳实践标准。如果出于我无法理解的原因需要为旧安装保留此选项，那么应该添加一个警告，指出当前配置违反了行业标准最佳实践，并建议使用符合标准的配置。
感谢您链接此主题。@awesomerobot 有权发表自己的观点，但他们也厚颜无耻地无视行业标准的最佳实践，并坚称一个众所周知、经常被报道且明确编码的错误“不是错误”，与已发布的行业标准最佳实践相比，我认为他们的观点并不令人信服。
即便如此，默认值也应反映更安全的配置，并且应该有一些指示来告知新手管理员禁用此选项构成了论坛上故意且不必要的安全和隐私漏洞。链接到 OWASP 条目或类似内容。
有人能告诉我禁用此选项可能更可取的场景吗？我真的不知道为什么这是一个有争议的问题，并想知道我是否遗漏了某种可以取代此设置所实现的默认启用安全模型的用例。如果无法提出这样的场景，那么此设置应始终启用，因此不应成为一个设置。
我认为，目前一切都按预期运行，所以我们不能真正将此视为一个#bug。但是，我们会例行重新评估我们的默认设置，您提出了一些值得考虑的有趣观点。
我将把它移到#ux，以便在那里继续讨论。
很简单……人们不擅长记住他们用来创建帐户的电子邮件地址，并且会联系管理员进行故障排除。
这类似于“强制第二因素”或“最小密码长度”——我认为一般的建议是始终要求第二因素，而密码最小长度的建议现在似乎比我们为普通用户设置的默认值要高……但安全建议和平均计算机技能之间也存在差距。
我并不强烈反对更改默认设置，但值得注意的是，它们可能会影响可用性。
在我看来，这似乎是 Discourse 默认应遵循最佳实践——就像几乎所有其他网站一样。
看起来我的实例已设置了相应的设置：
如果一个账户匹配 x@example.com，您将很快收到一封包含如何重置密码说明的电子邮件。
感谢大家就此 bug 提供的宝贵意见和视角。对我而言，这非常简单明了：Discourse 中存在一个众所周知的 bug，曾被像我一样的管理员和安全专家反复提出，但它被当作一个功能而非安全漏洞来处理：NIST: CWE-200: 向未经授权的参与者暴露敏感信息。
以论坛管理员因用户注册邮箱过多而不知所措的假设情况，来证明这种不安全的默认配置违反了行业标准最佳实践，这是没有意义的，因为无论此设置如何配置，使用“忘记密码”页面都不需要管理员介入：如果启用了更安全且符合标准的设置，用户只需在忘记邮箱对话框中查看他们的邮箱，就能知道该地址是否收到了密码重置邮件，这与对话框的解释完全一致，并且是所有现代、尊重隐私、符合标准的 Web 应用程序的常见做法。此外，以其他网站“也可能违反最佳实践”为由来证明这种违规行为，从安全和数据保护的角度来看，既不合逻辑也无说服力。我很难理解为什么我们要给管理员提供一个使他们的 Discourse 安装在安全性上和合规性上略有降低的“功能”，而没有任何明显的好处。
尽管如此，我还是完成了您指定的任务，@sam：
在列表中的前 15 个网站中，有 8/15 个不允许用户枚举（如果算上 Reddit，则是 9/16 个，并且可以为 Facebook 算 0.5 个，因为它只允许枚举用户明确批准公开的信息），而该列表中允许用户枚举的 7 个网站中，至少有 3 个因该决定而面临了严重的安全事件。
这有点不诚实，因为可以说主要的 Google 产品（Gmail）允许枚举。
对于电子邮件身份提供商上的账户是否存在，测试起来非常简单，因此没有多大意义将其包含在列表中。
列表中没有其他平台是（潜在地）自托管软件。
没有中央 Discourse 平台 - 网站管理员可以自由选择。
话虽如此，我同意应该提醒网站管理员默认选择好的设置。
也许可以有一个管理员可以调整的旋钮（我犹豫是否建议将其添加到向导中），以便轻松地收紧此类设置。
这不适用于任何带有注册页面的网站，而不仅仅是电子邮件服务提供商吗？我明白你的观点，即注册页面是潜在的隐私和数据漏洞来源，因此必须加以保护，但这与我们在此主题中讨论的用户身份验证流程不同。在此主题中，我们专门关注“忘记密码”对话框中的泄露。我的意思不是说：两者都绝对重要，需要仔细关注，并需要采取缓解措施来防止隐私和数据漏洞。通常，对于注册表单，您需要验证码，对于“忘记密码”端点，无论电子邮件是否有效，您都希望获得相同的响应。许多网站还通过验证码保护“忘记密码”端点。两个端点都应该进行速率限制。
我当然不是在试图不诚实。我认为“由于其他网站也不合规，因此不合规是可以的”这种说法在逻辑上并不合理，我只是在完成 Sam 的请求，并通过他提供的链接来提供他所寻求的“证据”，以减轻他可能有的任何担忧。
MediaWiki 软件被数万个网站和数千家公司和组织使用。它为维基百科提供支持，并且在很大程度上是自托管软件。
我当然鼓励管理员自由，我也不想让管理员或用户的生活变得更困难，但我认为在这种情况下，此设置的“优点”并不 outweigh “缺点”，并且没有任何管理员会真正想要此“功能”。就像我们不允许管理员强制执行最大密码长度一样，我们也不应允许他们通过在“忘记密码”对话框中允许此枚举漏洞来不必要地稍微降低其论坛的安全性。我认为我们应该完全删除该选项，并强制所有人遵循符合标准的做法。老实说，我认为大多数管理员都不会注意到或在意，但这将使所有 Discourse 安装中面向公共互联网的端点更加安全。如果我们必须包含该设置，那么它应该默认处于更安全的位置，并且应该清楚地标明不安全的位置，以便新手管理员了解为什么不推荐它。但我认为，简单地将此设置重构掉是最好的选择。我很乐意为此提交一个 PR。
我认为你不能孤立地看待这两者。在 Discourse 的注册过程中，有一个“电子邮件已被占用”的消息，很难看到有什么不同的处理方式。只要这个消息存在，就很难理解“我们找到了一个匹配的账户”这个消息有什么大问题。
我想，如果一个论坛只允许外部身份验证，那会有所不同。
我克服了仅仅因为你的风格而不同意你的冲动，我认为在实质上，你的立场是正确的，即默认选项应该是更安全的选择，至少在使用外部身份验证时是这样。我仍然不认为不那么安全的选择没有任何用处（我的论坛使用了 Discourse 的默认注册流程，所以我也不打算更改重置密码选项）。
顺便说一句，你让读者从上下文中猜测 XVideos 和 Xnxx（但不是 X）是色情网站，却费心解释亚马逊是“电子商务网站”，这让我笑了。
区分 Amazon.com 和 AWS。既然你问了：AWS 不允许用户枚举。
我同意你必须考虑用户身份验证流程的所有步骤以及它们如何协同工作。这极其重要，也是安全漏洞最常见的来源之一。如果你提到的注册页面上类似的电子邮件枚举错误没有得到妥善缓解，那么无论此主题的结果如何，都绝对应该进行修补。这将是 hide_email_address_taken 实现中的一个错误。关于这个潜在错误/疏忽的讨论可能应该在另一个主题中进行（并且可能带有 bug 标签）。
仅供参考，启用 hide email address taken 后，注册时也不会显示该消息（当在邀请时输入现有邮箱时，它也会更改邀请消息）。
我认为仅更改默认设置的一个可能复杂之处在于，它还内置了“需要完整邮箱才能重置密码”的功能，这可能会使事情过于复杂（尽管可能不是完全的障碍）。
谢谢。我可能会更改设置。我认为这个话题中的某些内容给我留下了错误的印象。
这是什么意思？是说不能仅凭用户名重置密码吗？
就是这个意思。 启用“隐藏邮箱地址已被占用”后，您需要输入账户邮箱本身才能重置密码，而不能只使用用户名。
我建议将 hide_email_address_taken SiteSetting 重命名为 prevent_password_recovery_by_username，然后为所有用户将不合规的行为从应用程序中重构出来。这将保持所有安装的密码重置功能不变，同时解决电子邮件枚举漏洞。我是一名熟练的 RoR + javascript 开发人员，我很乐意实现这个拉取请求；我快速浏览了代码库，可以看到这不会是一个庞大的 PR。
如果真的无法将此“功能”重构掉，那么我认为将这两个相关概念分离到单独的 SiteSetting 条目中仍然是有意义的。
