我正在开发一个服务器组件，它将为嵌入式客户端的请求提供服务，这也在我的控制之下。
现在一切都是测试版，安全性是这样的：
客户端通过 https 发送用户名/密码。
服务器返回访问令牌。
客户端使用自定义标头中的访问令牌通过 http 发出进一步的请求。
这对于一个演示来说很好，但它有一些问题需要在发布之前解决：
任何人都可以复制 正如一些用户回答的那样，这不是问题，因为它通过了 https。我的错。login 请求，重新发送它并取回访问令牌。
任何人都可以通过检查请求标头来监听并获取访问密钥。
我可以想到一个对称密钥加密，带有时间戳，这样我就可以拒绝重复的请求，但我想知道这种情况是否有一些众所周知的良好做法（这似乎很常见）。
非常感谢您的洞察力。
PS：为了以防万一，我在服务器上使用 Java，而客户端是用 C++ 编写的。
【问题讨论】：
标签： java security http encryption man-in-the-middle
常见的建议之一是 - 使用 https
除了在整个会话中使用 https 之外，中间攻击中的 https 人应该足够可靠。您甚至无需担心访问令牌 - https 会为您解决这个问题。
使用 http 进行进一步的请求似乎会引入一些漏洞。现在任何拥有网络嗅探器的人都可以拦截您的流量，窃取令牌并欺骗您的请求。你可以建立保护来防止它 - 令牌加密，使用一次令牌等，但这样做你将重新创建 https。
回到中间攻击中的 https 人 - 它基于某人将自己插入您的服务器和您的客户端之间并通过他们的代码汇集您的请求的能力。这一切都是可行的，即万一攻击者可以访问物理网络。这样的攻击者将面临的问题是他将无法给你一个正确的数字证书——他没有你用来签名的私钥。当通过浏览器访问 https 时，浏览器会向您发出警告，但仍然可以让您进入该页面。
在您的情况下，您的客户端将与服务器通信。并且您可以确保证书的所有正确验证都已到位。如果你这样做，你应该没问题
编辑
其次是 Yishai - 是的，这涉及到一些开销，主要是 CPU，但如果这些额外的开销将您的服务器推到了极限，那么您的应用程序就会遇到更大的问题
【讨论】：
第一部分看不懂，如果登录请求是https，怎么会有人复制呢？
关于第二部分，这是一个非常标准的会话劫持场景。见this question。当然，您在这里没有内置浏览器选项，但基本思想是相同的 - 要么仅在重要时通过安全连接发送令牌，要么以某种方式将令牌与发送设备相关联。
在浏览器中，基本上您所拥有的只是 IP 地址（这不是很好），但在您的情况下，您可能能够表达有关您的设备的特定内容，您可以根据请求验证以确保相同的令牌'没有被其他地方使用。
编辑：您可能很幸运，能够排除代理背后的 IP 地址更改，并将其实际用于此目的。
但归根结底，使用来自知名且经过审查的库的 https 比尝试在此处推出自己的 https 更安全。我意识到 https 是一种开销，但是自行开发 https 有很大的风险，可能会丢失攻击者可以利用的明显东西。
【讨论】：
第一个问题，只是为了解决这个问题：如果您对恶意客户端模拟访问足够关注，为什么不通过 HTTPS 进行整个对话呢？对于这个应用程序来说，最小的性能损失是否足够显着以至于不值得增加安全层？
其次，有人如何重放登录请求？如果我没记错的话，那是通过 HTTPS 进行的；如果连接设置正确，HTTPS 会使用一次性随机数防止重放攻击（请参阅here）。
【讨论】：