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