Rest 散列已知纯文本的危险

我有易于猜测的内部标识符（自动递增的数字），我希望让我的客户能够基于这些标识符访问资源

当然，我无法为他们提供如下URL：

https://example.com/order/13

因为他们可以很容易地猜测如何从这个URL访问order#14

因此，我考虑为他们提供一个标识符的盐散列，如：

https://example.com/order/4643ef

在哪里

4643ef… = sha256(13 + 'supersecretsalt')

---

从安全角度来看，这是一个好方法吗？

首先，您不应该仅仅基于uri授予对任何资源的访问权限。换句话说，用户A应该不能访问属于用户B的资源，即使他知道相关的uri。为了缓解这种情况，您应该在允许访问任何（机密的？）资源之前添加某种形式的身份验证和授权

这就是说，如果您仍然想混淆uri，您可能可以使用一个函数来实现这一点，而不是生成任何类型的散列。相反，对于每个订单ID，只需将GUID与之一起存储，然后在url中使用GUID时查找该ID

---

旁注：如果您确实想让您的客户仅根据url（即不需要标识）查找某些订单详细信息，您至少可以暂时使用该资源。您可以通过将有效截止日期等与GUID一起存储来实现这一点

现在，用户A将能够通过带有guid的url查看与其资源相关的信息，但可能仅持续3天。其他用户也可以访问它，但这种情况不太可能发生，因为很难猜测GUID，而且他们只有3天的时间来猜测GUID

如果用户A以后需要再次访问他的资源，也许您可以提供一种方法来扩展GUID的有效性，或者只提供一个指向同一资源但具有不同有效日期的新GUID

---

显然，您需要仔细考虑这是否符合您的特定情况和安全需要。

使用一个具有真值的表和一个guid或高度随机的字符串，在两者之间插入一个数据库查找？我也考虑过这一点。事实上，这样做要好得多，因为无论如何我都必须缓存哈希，否则我需要为每个访问上的每个对象计算哈希值。如果URI中的标识符是纯文本，那么问题是什么？无论您的服务器是否易于猜测，都应该明确验证访问资源的用户是否有权访问该资源。容易猜测的URI本身并不是一个安全问题。@sisyphus虽然我在这里大体上同意您的观点，但我可以很容易地想象出在什么情况下，最好保守orderId的秘密。使用例如GUID来提取真实ID的开销可能不会很大，而且可能会提供额外的安全层。谢谢您的回答！但是，您能否详细说明为什么URI不应被视为机密？它与任何其他形式的身份验证一样是可猜测/不可用的。这是一种特殊情况，因为GET请求可能会记录在不太可能记录为身份验证头的位置吗？@ooxi如果您指的是uri格式本身，我假设定期增加的数量（例如订单ID）比更复杂的GUID更容易猜测。至于为什么我不认为它是一个安全的秘密，有几个原因：一个GET请求必须在明文中通过网络发送，而一个帖子中的密码可以被加密；此外，还存在在不同位置（服务器、客户端、浏览器等）进行日志记录的问题，甚至可能是搜索引擎自动发现和索引的问题。适当的身份验证和/或有时间限制的访问至少可以部分缓解这一问题。