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

Question

我正在尝试针对这种情况提出潜在的安全漏洞（顺便说一句，我已经问过一个相关的问题several days ago，但是，从答案中，我已经意识到，解释精确的情况非常关键，因为很多答案都与此无关，我还包括了到目前为止我发现的漏洞以及如何缓解这些漏洞，因此我们将不胜感激。因此，我们继续：

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

b）用户的“流”为：

1. 用户访问网站，在特定时间段内订购车票，这将使他在某些位置（博物馆等）有特权
2. 成功下单后，网站将打印一个6个字母长的字符串（ID）。示例：GFZ-GFY。有26 ^ 6（〜3.08亿）种潜在组合。当然，这些ID将存储在安全的数据库中。
3. 然后，用户前往博物馆（或其他场所）并显示6个字母长的字符串。员工使用Web应用程序检查其有效性或将SMS发送到号码，立即获得有效性状态（在两种情况下，代码都会针对数据库进行查询以检查票证的有效性）。

到目前为止，我已经确定了2个潜在问题：

a）蛮力攻击

将在2个“攻击面”下发生这种情况：

1. 博物馆员工可以通过网络访问应用程序（以验证票证的有效性）。我减轻这种情况的方法是将每个用户帐户每天的查找次数限制为1,000。
2. 用户将能够检查其订单状态。我将通过几种方式缓解这种情况：首先，URL不是“公共”的，并且仅对购买票证的用户可用。其次，我将实施ReCaptcha v3，即IP禁止每小时超过10个失败的请求。
3. 一次“活动”票的数量预计为5000张（最高时），正常情况下约为500-1000张，因此考虑到有数亿种组合，则需要花费大量精力攻击者通过这种方式强行攻击。

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

1. 博物馆检查通行证的有效性后，如果他们再次对其进行检查，则会出现一条通知，指出：此通行证已在此时间：[时间-日期]检查过。
2. 尽管我打算重复使用相同的代码，但我会确保每个周期之间至少有90天的周期。也许有一些我不知道的漏洞。在“到期”日期之后90天后，该代码可以或不能再次使用。我要说的是，它将在可能使用的潜在（300+百万）代码的“池”中释放。也许这不是一个好主意？
3. 将为客户提供（发送至地址或指示您提货）空白卡状的“票”，其中将在上面写上代码（否则，他必须使用笔在票上）。这将使攻击变得更加困难，因为攻击者现在需要同时访问代码和可以使用相同材料打印此类卡的打印机。

您是否还可以看到其他可能的攻击方式？我目前的缓解方法还缺少什么？

Answer 1

我还将为您的数据库受到损害的情况做计划，例如通过SQL注入。不用存储代码纯文本，您可以使用任何适当的密码哈希函数并仅存储代码的哈希。验证步骤与密码相同。

如果没有用户ID，则必须通过数据库查询才能检索该代码，那么您将无法使用盐析。在这种情况下，我们可以使用密钥派生函数（KDF），该函数需要一些时间来计算哈希值，以使暴力破解更加困难。缺少盐会导致下一点：

使用更长的代码会让我感到更舒服。如果我正确阅读该表，则由于birthday problem，在您的设置下找到有效代码的可能性（〜28bit / 3000个活动代码）约为0.001。具有9个字符的代码可能是一个不错的折衷方案，因为它们不区分大小写，仍可以快速键入，但允许5E12组合。这样的代码可以保留在数据库中，因此可以告诉您凭单已过期，无需重复使用它们。即使使用KDF，强行强制使用300万个哈希也不是什么大障碍，而5E12组合的强行使用则更成问题。

Answer 2

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

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

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

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