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

Question

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

现在，所有内容都是beta版本，其安全性如下所示：

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

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

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

这对于演示很好，但是在发布它之前，需要解决一些问题：

• 任何人都可以复制 login请求，然后重新发送并获得访问令牌。 正如一些用户回答的那样，这不是问题，因为它遍历了https。 我的错。

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

我可以想到带有时间戳的对称密钥加密，因此我可以拒绝重复的请求，但是我想知道这种情况是否存在一些众所周知的良好做法（这很常见）。

非常感谢您的见解。

PS：我正在为服务器使用Java，并且客户端以C ++编码，以防万一。

Answer 1

常见建议之一是-使用https

除了在整个会话中使用https的中间攻击之外的https man应该足够可靠。 您甚至不必担心访问令牌-https会为您解决这一问题。

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

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

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

编辑

其次，Yeshai-是的，涉及一些开销，主要是CPU，但是如果这笔额外开销使服务器负担过重，则您的应用程序会遇到更大的问题

Answer 2

第一个问题，就是要解决这个问题：如果您对恶意的客户端模拟访问有足够的关注，为什么不通过HTTPS进行整个对话呢？ 最低性能对这个应用程序是否足够重要，以至于不值得增加额外的安全性？

第二，有人如何重播登录请求？ 如果我没记错的话，那是通过HTTPS进行的。 如果连接设置正确，HTTPS将使用一次性随机数来防止重放攻击（请参阅此处 ）。

Answer 3

我没有得到第一部分，如果登录请求是https，那么谁能复制它呢？

\n

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

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

编辑：您可能在这里很幸运，并且可以排除代理后面的IP地址更改，并且可以将其实际用于此目的。

但是，归根结底，使用来自知名且经过审查的库中的https比尝试将自己的脚本放到这里要安全得多 。 我意识到https是一项开销，但是如果您自己进行滚动，则会遗漏一些攻击者可以利用的明显事物的巨大风险。