Windows 上 Java 和 Python 之间的 IPC 对当前用户安全
我们有一个需要客户端证书身份验证的 Rest API。该 API 由用户可以运行的 Python 脚本集合使用。为了使用户不必在每次运行其中一个脚本时输入客户端证书的密码，我们在 java 中创建了这个代理进程，用户可以在后台启动并运行该进程，该进程保存着内存中的用户证书密码（我们只需在 JVM 中设置 javax.net.ssl.keyStorePassword 属性）。脚本与此进程通信，该进程仅将 Rest API 调用转发到服务器（添加证书凭据）。
为了在脚本和代理进程之间进行 IPC，我们只使用套接字。问题在于，套接字带来了安全风险，因为有人可以通过他人计算机上的代理进程端口进行通信，从而使用他人的证书来使用 Rest API。我们通过使用 java 安全性仅允许从本地主机连接到端口，从而在一定程度上降低了风险。我认为虽然理论上有人仍然可以通过远程连接到机器然后使用端口来做到这一点。有没有办法进一步限制当前Windows用户对该端口的使用？或者也许我可以使用另一种形式的 IPC 来使用当前的 Windows 用户进行授权？
我们使用 Java 进行代理流程，只是因为我们团队中的每个人都比 Python 更熟悉 Java，但如果有帮助的话可以用 python 重写。
编辑： 只是记得在代理进程中使用 java 的另一个原因是我们一直坚持使用 python v2.6，并且在此版本中似乎不支持带有客户端证书的 https（至少不使用第 3 方库） 。
We have a Rest API that requires client certificate authentication. The API is used by this collection of python scripts that a user can run. To make it so that the user doesn't have to enter their password for their client certificate every time they run one of the scripts, we've created this broker process in java that a user can startup and run in the background which holds the user's certificate password in memory (we just have the javax.net.ssl.keyStorePassword property set in the JVM). The scripts communicate with this process and the process just forwards the Rest API calls to the server (adding the certificate credentials).
To do the IPC between the scripts and the broker process we're just using a socket. The problem is that the socket opens up a security risk in that someone could use the Rest API using another person's certificate by communicating through the broker process port on the other person's machine. We've mitigated the risk somewhat by using java security to only allow connections to the port from localhost. I think though someone in theory could still do it by remotely connecting to the machine and then using the port. Is there a way to further limit the use of the port to the current windows user? Or maybe is there another form of IPC I could use that can do authorization using the current windows user?
We're using Java for the broker process just because everyone on our team is much more familiar with Java than python but it could be rewritten in python if that would help.
Edit: Just remembered the other reason for using java for the broker process is that we are stuck with using python v2.6 and at this version https with client certificates doesn't appear to be supported (at least not without using a 3rd party library).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最简单的方法是使用基于 cookie 的访问控制。在用户的配置文件/主目录中有一个包含 cookie 的文件。让 Java 服务器生成并保存 cookie，并让 Python 客户端脚本将 cookie 作为任何 TCP 连接上的第一个数据发送。
只要对手无法获取 cookie，这就是安全的，而 cookie 应该受到文件系统 ACL 的保护。
The most simple approach is to use cookie-based access control. Have a file in the user's profile/homedirectory which contains the cookie. Have the Java server generate and save the cookie, and have the Python client scripts send the cookie as the first piece of data on any TCP connection.
This is secure as long as an adversary cannot get the cookie, which then should be protected by file system ACLs.
我想我已经提出了一个受上面马丁的帖子启发的解决方案。当代理进程启动时，我将创建一个监听 IPC 端口的迷你 http 服务器。另外，在启动过程中，我会将一个包含随机生成的密码（每次启动都不同）的文件写入用户的主目录，以便只有用户才能读取该文件（或管理员，但我认为我不需要担心这一点） ）。然后，我将通过要求发送到那里的所有 http 请求使用密码来锁定 IPC 端口。这有点像鲁布·戈德堡式的，但我认为它会起作用。
I think I've come up with a solution inspired by Martin's post above. When the broker process starts up I'll create an mini http server listening on the IPC port. Also during startup I'll write a file containing a randomly generated password (that's different every startup) to the user's home directory so that only the user can read the file (or an administrator but I don't think I need to worry about that). Then I'll lock down the IPC port by requiring all http requests sent there to use the password. It's a bit Rube Goldberg-esque but I think it will work.