票务实施中的潜在安全漏洞

Posted 2023-02-19

【中文标题】票务实施中的潜在安全漏洞

【英文标题】：Potential security vulnerabilities in a ticketing implementation

【发布时间】：2019-02-08 21:51:41

【问题描述】：

我正在尝试集思广益这种场景的潜在安全漏洞（顺便说一句，我已经提出了一个相关问题 several days ago，但是，从答案中，我意识到解释 EXACT 场景非常重要，因为很多由于这个原因，答案中的一些（有点）无关紧要。我还包括了迄今为止我发现的漏洞，以及如何缓解这些漏洞，因此我们将不胜感激。所以我们开始吧：

a) 整个系统将是一个“票务”系统，但不是普通票，而是“通行证”系统。含义：客户去订购一张“通行证”票，这使他可以在特定时间段内获得某些地方的某些特权（例如免费进入博物馆）。意思是，这是一张在 1-7 天（但不超过 7 天）后过期的票。

b) 用户的“流量”是：

用户访问网站，订购特定时间段的门票，这让他在特定地点（博物馆等）享有特权 成功下单后，网站会打印一个 6 个字母长的字符串（ID）。示例：GFZ-GFY。有 26^6（约 3.08 亿）种潜在组合。当然，这些 ID 将存储在安全数据库中。 然后用户前往博物馆（或其他场所）并展示 6 个字母长的字符串。员工通过网络应用程序或向号码发送短信检查其有效性，立即获取有效性状态（在这两种情况下，代码将查询数据库以检查票的有效性）。

到目前为止，我发现了 2 个潜在问题：

a) 蛮力攻击

有 2 个“攻击面”会发生这种情况：

博物馆员工可以通过门控访问网络应用程序（以验证门票有效性）。我缓解这种情况的方法是将每个用户帐户的查找次数限制为每天 1000 次。 用户将能够检查其订单的状态。我将通过多种方式缓解这种情况：首先，该 URL 不是“公开的”，并且仅对购买门票的用户可用。其次，我将实施ReCaptcha v3，IP 禁止每小时超过 10 个不成功的请求。 一次“活动”票证的数量预计为 5000（在高峰期），正常情况下约为 500-1000，因此考虑到数以亿计的组合，这将需要付出巨大的努力攻击者暴力破解。

攻击者可以采取的第二种（也是更简单的）方法是简单地购买一张票并重新发布它，或者在线发布它以供任何人使用。我减轻这种情况的方法是：

博物馆对通行证的有效性进行核对后，如果再次核对，会提示：此通行证已在此地点核对，此时：[时间-日期]。 虽然我确实计划重复使用相同的代码，但我会确保两个周期之间至少有 90 天的时间。也许这样做有一些我不知道的漏洞。在“到期”日期后 90 天后，代码可能或可能不再使用。我要说的是，它将在可以使用的潜在（300+ 百万）代码的“池”中发布。也许这不是一个好主意？ 将给客户（发送到一个地址，或指示取货）一张类似空白卡片的“票”，上面将写上代码（或者他必须用票上的笔）。这将使攻击更难进行，因为攻击者现在需要同时访问代码和可以打印具有相同材料的此类卡片的打印机。

您是否发现任何其他可以进行的潜在攻击？我目前的缓解方法有什么遗漏吗？

【参考方案1】：

我还会为您的数据库遭到破坏的情况做好准备，例如通过 SQL 注入。您可以使用任何合适的密码哈希函数并仅存储代码的哈希值，而不是存储代码纯文本。验证过程与密码相同。

如果没有用户 id，代码必须可以通过数据库查询来检索，那么您不能使用盐渍。在这种情况下，我们可以使用密钥派生函数 (KDF)，它需要一些时间来计算散列以使暴力破解更加困难。缺少的盐导致下一点：

我会觉得使用更长的代码更舒服。如果我正确地阅读了表格，那么使用您的设置（~28bit / 3000 个活动代码）找到有效代码的概率约为 0.001，因为 birthday problem。具有 9 个字符的代码可能是一个很好的折衷方案，因为它们不区分大小写，它们仍然可以快速输入，但允许 5E12 组合。这样的代码可以留在数据库中，因此可以判断票已过期，无需重新使用它们。即使使用 KDF，暴力破解 300 万个哈希也不是什么大问题，暴力破解 5E12 组合的问题要大得多。

【讨论】：

我不确定是否可以通过将 Google Recaptcha 设置为“高”级别来保护所有可能的条目，这样的蛮力是可能的。

@anemaria20 - 暴力破解不是在网站上在线完成的，当攻击者已经知道数据库的内容时，它可以离线应用（Recaptcha 没有保护）。也许你想看看我关于SQL-injection 的演示，然后你可以决定这是否是一个威胁。如果你总是使用准备好的语句并且没有外部库，那么你应该没问题。

【参考方案2】：

您似乎已经花费了相当多的时间来考虑这一点，并且您已经确定了您最大的潜在攻击面。

Martinstoeckli 通过提高 SQL 注入和蛮力的潜力确定了我认为下一个最大的问题。根据我的经验，对 SQL 注入的最佳缓解就是确保所有输入都得到适当的清理。蛮力问题永远无法完全解决，6 个字符的密钥有点容易破解。包括使用 KDF 似乎是一个好主意，但您还必须考虑对数据库的性能影响。估计有 500-1000 个用户/密钥，我认为这不会是一个大问题。

我建议不要重复使用密钥，因为取决于它们的存储方式，一段时间后可能会导致哈希冲突攻击，具体取决于它们的存储方式。

在这些问题之后，我实际上建议您研究一下您如何托管此应用程序的细节。它是托管在您可以访问的物理服务器上，还是位于云中某处的虚拟机？每一个都会有自己的风险。