托管签名 jar 时的安全注意事项
在互联网上托管签名 jar 的安全隐患是什么？
据我了解 jar 签名，一旦用户选择自动接受证书，签名的 jar 是否来自您的域、从另一个域链接或托管在另一个域上并不重要。 例如，Sun 使用此方法通过提供链接到驱动程序的（托管）签名 jar 来为小程序提供 OpenGL 支持。 那么，作为我提供的 java 代码的开发人员和证书签名者，我应该采取哪些预防措施呢？
What are the security implications for hosting signed jars on the internet?
As I understand jar signing, once a user choose to auto-accept a certificate, it doesn't matter if the signed jar came from your domain, linked from another domain or hosted on another domain. For example, Sun uses this method to give applets OpenGL support, by providing (hosted) signed jar that link to the driver. So are there any precautions I should make as the developer and certificate-signer of the java-code I make available?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据上下文，您依赖安全管理器和关联的安全策略来执行正确的操作。 一般来说，除非您正在执行自己的类加载器魔法，否则不需要执行任何特殊操作。 如果您可以控制安全策略（例如在 java 应用程序而不是 applet 中），您可以授予仅对某些其他代码调用 jar 的权限。 如果您依靠代码库来区分代码，则 https URL 更好。 如果您知道访问应该来自哪里/谁，那么限制对网络服务器上的 jar 的访问也没有什么坏处，但可能会带来更多麻烦。
但是，您应该始终记住，API 的调用者可能不是您的代码，并且可能是恶意的。 因此，在威胁建模中，您应该考虑如果恶意用户能够以某种方式访问您的代码公开的 API 提供的功能，他们可能会执行哪些操作。 安全管理器应该检查调用堆栈以防止这种情况发生。 但是，例如，如果您的签名 jar 有一个方法 LaunchMissiles() ...您可能想询问用户是否确定。 您可能还想对用户进行身份验证。
您也不应该依赖用户在任何安全警告上单击正确的按钮，特别是当它涉及证书和 URL 等时 - 大多数用户属于以下两类之一：由于不理解而在任何警告上单击“确定”的用户以及那些因不理解而在任何警告上单击“取消”的人。
Depending on the context, you are relying on the security manager and associated security policy to do the right thing. Generally unless you are doing your own classloader magic, you shouldn't need to do anything special. If you have control of the security policy, (for example in a java application rather than applet) you can grant permissions to call your jars only to certain other code. If you rely on codebase to distinguish code, a https URL is better. It is also no harm to limit access to the jars on the webserver if you know where/who the accesses should be coming from, but is probably more trouble than it is worth.
However, you should always bear in mind that the caller of your API may not be your code, and may be malicious. So in your threat modelling, you should think about what a malicious user may be able to do if they somehow had access to the functionality given by the API your code exposes. The security manager is supposed to check up the call stack to prevent this kind of thing. But if for example your signed jar has a method LaunchMissiles() ...you might want to ask the user if they are sure anyway. And you might want to authenticate the user too.
Nor should you necessarily rely on the user to click the right button on any security warning, especially if it refers to certificates and URLS etc - most users fall into one of two categories: those who click OK on any warning because they don't understand it, and those who click Cancel on any warning because they don't understand it.