客户端和服务器之间的安全连接
我正在开发一个服务器组件，它将为嵌入式客户端的请求提供服务，这也在我的控制之下。
现在一切都是测试版，安全性的工作原理如下：
客户端通过 https 发送用户名/密码。
服务器返回访问令牌。
客户端使用自定义标头中的访问令牌通过 http 发出进一步的请求。
这对于演示来说很好，但在发布之前需要解决一些问题：
任何人都可以复制正如一些用户回答的那样，这不是问题，因为它通过 https 进行。我的错误。登录请求，重新发送它并获取访问令牌任何人都可以通过检查请求标头来侦听并获取访问密钥。
我可以想到对称密钥加密，带有时间戳，这样我就可以拒绝重复的请求，但我想知道这种情况是否有一些众所周知的良好实践（这似乎很常见）。
非常感谢您的见解。
PS：我使用 Java 作为服务器，客户端使用 C++ 编码，以防万一。
I'm developing a server component that will serve requests for a embedded client, which is also under my control.
Right now everything is beta and the security works like this:
client sends username / password over https.
server returns access token.
client makes further requests over http with the access token in a custom header.
This is fine for a demo, but it has some problems that need to be fixed before releasing it:
Anyone can copy aAs some users replied this is not an issue since it goes over https. My mistake.loginrequest, re-send it and get an access token back.Anyone can listen and get an access key just by inspecting the request headers.
I can think of a symmetric key encryption, with a timestamp so I can reject duplicate requests, but I was wondering if there are some well known good practices for this scenario (that seems a pretty common).
Thanks a lot for the insight.
PS: I'm using Java for the server and the client is coded in C++, just in case.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不明白第一部分，如果登录请求是https，怎么可能有人复制它？关于第二部分，t这是一个非常标准的会话劫持设想。请参阅此问题。当然，这里没有内置的浏览器选项，但基本思想是相同的 - 要么仅在重要时通过安全连接发送令牌，要么以某种方式将令牌与发送设备相关联。在浏览器中，基本上您拥有的只是 IP 地址（这不是很好），但在您的情况下，您可能能够表达有关您的设备的特定信息，您可以根据请求进行验证，以确保不会使用相同的令牌从其他地方使用。
编辑：您可能很幸运，能够排除代理背后的 IP 地址更改，并实际将其用于此目的。
但归根结底，使用来自知名且经过审查的库的 https 比尝试在这里推出自己的库要安全得多。我意识到 https 是一种开销，但自行推出 https 会带来很大的风险，因为它会遗漏攻击者可以利用的明显内容。
I don't get the first part, If the login request is https, how can anyone just copy it?Regarding the second part, tThis is a pretty standard session hijacking scenario. See this question. Of course you don't have the built-in browser options here, but the basic idea is the same - either send the token only over a secure connection when it matters, or in some way associate the token with the sending device.In a browser, basically all you have is IP address (which isn't very good), but in your case you may be able to express something specific about your device that you validate against the request to ensure the same token isn't being used from somewhere else.
Edit: You could just be lucky here and be able to rule out the IP address changing behind proxies, and actually use it for this purpose.
But at the end of the day, it is much more secure to use https from a well-known and reviewed library rather than trying to roll your own here. I realize that https is an overhead, but rolling your own has big risks around missing obvious things that an attacker can exploit.
第一个问题，只是为了解决这个问题：如果您非常担心恶意的客户端模仿者访问，为什么不通过 HTTPS 进行整个对话呢？对于该应用程序来说，最小的性能影响是否足够大，以至于不值得增加安全层？
其次，如何重放登录请求？如果我没记错的话，这是通过 HTTPS 进行的；如果连接设置正确，HTTPS 使用一次性随机数防止重放攻击（请参阅
First question, just to get it out there: if you're concerned enough about nefarious client-impersonator accesses, why not carry out the entire conversation over HTTPS? Is the minimal performance hit significant enough for this application that it's not worth the added layer of security?
Second, how can someone replay the login request? If I'm not mistaken, that's taking place over HTTPS; if the connection is set up correctly, HTTPS prevents replay attacks using one-time nonces (see here).
常见的建议之一是 - 使用 https
https 中间人攻击，除了在整个会话中使用 https 应该足够可靠。您甚至不需要担心访问令牌 - https 会为您处理这个问题。
使用 http 进行进一步请求似乎会引入一些漏洞。现在，任何拥有网络嗅探器的人都可以拦截您的流量、窃取令牌并欺骗您的请求。您可以构建保护来防止它 - 令牌加密、使用一次令牌等。但这样做时您将重新创建 https。
回到 https 中间人攻击 - 它基于某人将自己插入到您的服务器和客户端之间并通过他们的代码传送您的请求的能力。这一切都是可行的，即如果攻击者可以访问物理网络。这样的攻击者将面临的问题是，他将无法为您提供正确的数字证书 - 他没有您用于签名的私钥。当通过浏览器访问https时，浏览器会向您发出警告，但仍然可以让您访问该页面。
在您的情况下，您的客户端将与服务器进行通信。您可以确保证书的所有正确验证均已到位。如果你这样做，你应该没问题
编辑
Seconding Yishai - 是的，涉及一些开销，主要是 CPU，但如果这种额外的开销使你的服务器超出了范围，你的应用程序就会遇到更大的问题
One of the common recommendations is - use https
https man in the middle attack aside using https for the entire session should be reliable enough. You do not even need to worry about access tokens - https takes care of this for you.
Using http for further requests seems to introduce some vulnerabilities. Now anybody with a network sniffer can intercept your traffic steal the token and spoof your requests. you can build protection to prevent it - token encryption, use once tokens, etc. but in doing so you will be re-creating https.
Going back to the https man in the middle attack - it is based on somebody's ability to insert himself between your server and your client and funnel your requests through their code. It is all doable i.e. in case the attacker has access to the physical network. The problem such attacker will face is that he will not be able to give you a proper digital certificat - he does not have the private key you used to sign it. When https is accessed through a browser, the browser gives you a warning but still can let you through to the page.
In your case it is your client who will communicate with the server. And you can make sure that all proper validations of the certificate are in place. If you do that you should be fine
Edit
Seconding Yishai - yes some overhead is involved, primarily CPU, but if this additional overhead pushes your server over board, you have bigger problems with your app