我正在寻找有关对 HTTP 请求进行身份验证和签名(完整性检查)的最佳实践的一些指导/意见。我对使用的语言和技术保持相当开放的态度，但基本参数和要求如下:
- 需要身份验证和完整性检查。
- 请求包含敏感数据并将通过 HTTPS 传递，但我不能假设攻击者无法嗅探该请求，无论是在它被 HTTPS 加密之前(在客户端通过一些非法安装的软件)还是在服务器端，例如通过放置在 HTTPS 端点和实际服务器之间的嗅探器。 HTTPS 加密/解密处理已传递给外部负载平衡器，因此攻击者有一个小窗口可以在负载平衡器和服务器之间插入嗅探器。
- 我需要确保无法伪造交易。
- 我需要确保无法重放交易。
- 请求可以是 GET 或 POST，因此任何额外数据都需要保持在 GET 请求的最大大小限制内。
我们考虑过的事情:
- 每个请求的用户名/密码。我想这可以保证身份验证，但如果攻击者可以嗅探用户名/密码对，那么一切都会失败。
- 每个请求的私钥签名。服务器将拥有公钥，只有客户端拥有私钥。这保证了完整性，因为只有客户端可以生成签名，但服务器可以检查签名。它通常也能保证身份验证，因为私钥不是请求数据的一部分，无法被嗅探到。然而，它本身并不会阻止重放交易，因为具有相同数据的 2 个交易将具有相同的签名。
- 使用加密客户端随机数 ( https://en.wikipedia.org/wiki/Cryptographic_nonce ) 作为请求数据的一部分，并将其包含在要签名的数据中。我们遇到了这些问题，尤其是当它们在客户端生成时，因为如果它们不够随机，那么攻击者可以找出它们是如何生成的，然后攻击者可以在客户端生成相同的序列，这可能导致拒绝服务攻击，因为客户端将尝试重新使用攻击者已经使用过的随机数。已考虑在服务器端生成随机数，但这是一项额外的事务，并且可能会带来性能问题。
- 在请求数据中包含日期/时间，但这可能会导致客户端时钟和服务器时钟不同步的问题。
如果某些管理员决定将此标记为重复项，以下是我认为未完全解决此问题的全部范围的其他问题:
最佳答案
假设客户端和服务器之间是 1-1 的关系，带有计数器的 HMAC 可以解决这个问题。
客户端和服务器有一个共享的 128 位 key 。
客户端发送的消息具有带 key 的 HMAC 和计数器。建议使用 SHA-256，因为 SHA-1 即将淘汰(SHA-1 HMAC 仍然被认为是安全的，但这是另一回事)。
例如
example.com?message=foo&counter=1&hmac=35ed8c76e7b931b06f00143b70307e90f0831682e7bdce2074ebb5c509d16cfb`
(This tool 用于带有 secret bar 的帖子。)
HMAC 是根据 message=foo&counter=1 计算的。
现在，一旦服务器验证了 HMAC 并检查了计数器，服务器的计数器就会增加到 2。现在服务器将不会接受计数器小于 2 的任何经过身份验证的消息。
JSON Web Tokens可以使用，以便您以标准格式执行上述操作。您可以对多个客户端执行上述操作，但是您需要跟踪每个客户端的计数器服务器端，并且客户端必须在消息中标识自己。如果您决定为每个客户端使用不同的 key ，那么管理共享 secret 是最棘手的部分。
关于security - 验证并签署 HTTP 请求，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34938286/