客户端和服务器之间的安全连接

Question

我正在开发一个服务器组件，它将为嵌入式客户端提供服务，这也是我控制的。

现在一切都是测试版，安全性就像这样：

1. 客户端通过https发送用户名/密码。

2. 服务器返回访问令牌。

3. 客户端使用自定义标头中的访问令牌通过http进行进一步请求。

这适用于演示，但它有一些问题需要在发布之前修复：

• 任何人都可以复制login请求，重新发送并获取访问令牌。正如一些用户回复说这不是问题，因为它超过了https。我的错误。

• 任何人都可以通过检查请求标头来监听并获取访问密钥。

我可以想到一个对称的密钥加密，带有时间戳，所以我可以拒绝重复的请求，但我想知道这个场景是否有一些众所周知的良好实践（这似乎很常见）。

非常感谢您的见解。

PS：我正在使用Java作为服务器，而客户端是用C ++编写的，以防万一。

Answer 1

其中一项常见建议是 - 使用https

https man在中间攻击中使用https进行整个会话应该足够可靠。您甚至不需要担心访问令牌 - https会为您解决此问题。

使用http进一步请求似乎会引入一些漏洞。现在任何有网络嗅探器的人都可以拦截您的流量窃取令牌并欺骗您的请求。你可以建立保护来防止它 - 令牌加密，使用一次令牌等，但这样做你将重新创建https。

回到中间攻击中的https人 - 这是基于某人能够在您的服务器和客户端之间插入自己并通过他们的代码汇集您的请求的能力。这一切都是可行的，即在攻击者可以访问物理网络的情况下。攻击者将面临的问题是，他无法为您提供适当的数字证书 - 他没有您用来签名的私钥。当通过浏览器访问https时，浏览器会向您发出警告，但仍然可以让您访问该页面。

在您的情况下，您的客户将与服务器进行通信。并且您可以确保证书的所有正确验证都已到位。如果你这样做，你应该没事的

修改

借调Yishai - 是的，涉及到一些开销，主要是CPU，但是如果这个额外的开销会将您的服务器推到一边，那么您的应用程序就会出现更大的问题

Answer 2

第一个问题，只是为了得到它：如果你对恶意的客户端模仿访问充分关​​注，为什么不通过HTTPS进行整个对话？对于这个应用程序来说，最小性能是否足够重要，它不值得增加安全层？

其次，有人如何重播登录请求？如果我没弄错的话，那就是通过HTTPS发生的;如果连接设置正确，HTTPS会使用一次性随机数防止重放攻击（请参阅here）。

Answer 3

我没有得到第一部分，如果登录请求是https，那么任何人都可以复制它？

关于第二部分，t 这是一个非常标准的会话劫持场景。见this question。当然，这里没有内置的浏览器选项，但基本思路是相同的 - 要么在重要时通过安全连接发送令牌，要么以某种方式将令牌与发送设备相关联。

在浏览器中，基本上所有的都是IP地址（这不是很好），但在您的情况下，您可能能够表达您针对请求验证的设备的特定内容，以确保相同的令牌不是从其他地方使用。

编辑：你可以在这里幸运，并能够排除在代理服务器后面更改的IP地址，并实际上将其用于此目的。

但是在一天结束时，使用来自知名且经过审核的库中的https而不是尝试在这里推广自己的 更安全。我意识到https是一种开销，但滚动你自己有很大的风险，可以找到攻击者可以利用的明显事物。