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

Question

我正在尝试为这种情况集体讨论潜在的安全漏洞（顺便说一句，我已经问了一个相关问题several days ago，但是，从答案中，我已经意识到解释EXACT场景非常关键，因为许多答案都是（因为这个而无关紧要。我还列出了我到目前为止已经确定的漏洞，以及如何减轻这些漏洞，所以对它们的反馈将不胜感激。所以我们走了：

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

b）用户的“流程”是：

1. 用户进入网站，在特定时间段内订票，这使他在某些地点（博物馆等）获得额外津贴。
2. 订单成功后，网站会打印一个6个字母的长字符串（一个ID）。示例：GFZ-GFY。有26 ^ 6（~308亿）潜在组合。当然，这些ID将存储在安全的数据库中。
3. 用户然后去博物馆（或其他场所）并显示6个字母长的字符串。员工通过网络应用程序检查其有效性或向数字发送短信，立即获得有效状态（在这两种情况下，代码将查询数据库以检查故障单有效性）。

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

a）暴力攻击

将会出现2个“攻击面”：

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

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

1. 在博物馆检查通行证的有效性后，如果他们再次检查通行证，将会收到一条通知：此时此地点已经检查过此通行证：[时间 - 日期]。
2. 虽然我计划重新使用相同的代码，但我会确保在两个句点之间至少有90天的时间段。也许有一些我不知道这样做的漏洞。在“到期”日期过去90天后，代码可以不再使用。我所说的就是它将在可以使用的潜在（3亿多个）代码的“池”中发布。也许这不是一个好主意？
3. 客户将被发送（发送到一个地址，或被指示提取），一张类似空白卡的“票证”，代码将被写在上面（或者他必须用笔在上面写上代码）票）。这将使攻击变得更难，因为攻击者现在需要同时访问代码+可以使用相同材料打印此类卡的打印机。

你看到任何其他潜在的攻击可以做到吗？在我目前的缓解方法中，有什么我想念的吗？

Answer 1

我还计划你的数据库被泄露的情况，例如通过SQL注入。您可以使用任何正常的密码哈希函数并仅存储代码的哈希值，而不是存储代码纯文本。验证过程与密码相同。

如果没有用户ID，则必须使用数据库查询检索代码，然后才能使用salting。在这种情况下，我们可以使用密钥派生函数（KDF），这需要一些时间来计算哈希以使暴力破解变得更难。缺少盐导致下一点：

使用更长的代码我感觉更舒服。如果我正确读取表格，由于birthday problem，使用您的设置（~28bit / 3000活动代码）找到有效代码的概率约为0.001。具有9个字符的代码可能是一个很好的折衷方案，因为它们不区分大小写，它们仍然可以快速输入，但允许5E12组合。这些代码可以保留在数据库中，因此可以判断故障单已过期，无需重新使用它们。即使使用KDF，暴力逼迫300万个哈希也不是一大障碍，5E12组合的强制攻击更是一个问题。

Answer 2

你似乎花了相当多的时间来考虑这个问题，你已经确定了最大的潜在攻击面。

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

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

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