Java 脚本安全性（JRuby、Jython、Groovy、BeanShell 等）
我希望运行一些未经验证的脚本（用尚未确定的语言编写，但需要基于 Java，因此 JRuby、Groovy、Jython、BeanShell 等都是候选者）。 我希望这些脚本能够执行某些操作并限制执行其他操作。
通常，我会使用 Java 的 SecurityManager 并完成它。 这非常简单，让我可以限制文件和网络访问、关闭 JVM 的能力等。这对于我想要阻止的高级内容非常有效。
但我想允许一些东西，但只能通过我提供的自定义 API/库。 例如，我不想允许直接网络访问打开到 yahoo.com 的 URLConnection，但如果使用 MyURLConnection 完成，我就可以了。 也就是说，我想要允许一组方法/类，然后我想要禁止其他所有内容。
我不认为这种类型的安全性可以通过标准 Java 安全模型来实现，但也许可以。 我对脚本语言本身的性能或灵活性没有具体要求（脚本将是对我的 API 的简单过程调用，具有基本的循环/分支）。 因此，即使是对每个反射调用进行安全检查的“大”开销对我来说也是可以的。
建议？
I'm looking to run some un-verified scripts (written in a yet-to-be-determined language, but needs to be Java-based, so JRuby, Groovy, Jython, BeanShell, etc are all candidates). I want these scripts to be able to do some things and restricted from doing other things.
Normally, I'd just go use Java's SecurityManager and be done with it. That's pretty simple and lets me restrict file and network access, the ability to shutdown the JVM, etc. And that will work well for the high level stuff I want to block off.
But there is some stuff I want to allow, but only via my custom API/library that I've providing. For example, I don't want to allow direct network access to open up a URLConnection to yahoo.com, but I am OK if it is done with MyURLConnection. That is - there is a set of methods/classes that I want to allow and then everything else I want to be off limits.
I don't believe this type of security can be done with the standard Java security model, but perhaps it can. I don't have a specific requirement for performance or flexibility in the scripting language itself (the scripts will be simple procedural calls to my API with basic looping/branching). So even a "large" overhead that checks a security check on every reflection call is fine by me.
Suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您也许可以使用自定义类加载器，在委托给其父级之前检查链接到类的情况。
您可以创建自己的权限，检查安全敏感 API 中的权限，然后在调用底层 API 时使用
AccessController.doPrivileged恢复适当的权限。您需要确保脚本引擎本身是安全的。 Sun JDK 中的 Rhino 版本应该没问题，但不能保证。 显然，您需要确保脚本可用的所有内容都是安全的。
You may be able to use a custom class loader that does vets linking to classes before delegating to its parent.
You can create your own permissions, check for those in your security sensitive APIs and then use
AccessController.doPrivilegedto restore appropriate privileges whilst calling the underlying API.You need to make sure that the scripting engine itself is secure. The version of Rhino in the Sun JDK should be okay, but no guarantees. Obviously you need to make sure everything available to the script is secure.
在 Groovy 中，您完全可以执行您提到的操作。 其实很容易。 您可以轻松限制在受信任环境中运行的不受信任脚本的权限，允许使用您自己的 api，从而可以执行不受信任的操作。
http://www.chrismoos.com/2010/ 03/24/groovy-scripts-and-jvm-security/
In Groovy, you can do exactly what you mentioned. Actually very easy. You can easily limit permissions of untrusted scripts running in a trusted environment, allow usage of your own api, which in turn can do untrusted things.
http://www.chrismoos.com/2010/03/24/groovy-scripts-and-jvm-security/
免责声明：我不是 Java 安全 API 方面的专家，因此可能有更好的方法来做到这一点。
我为基于 Java 的开源企业 CMS Alfresco 工作，我们实现了与您所描述的类似的内容。 我们希望允许脚本编写，但仅向脚本引擎公开 Java API 的子集。
我们选择 Rhino Engine 来编写 JavaScript 脚本。 它允许您控制向 JavaScript 公开哪些 API，从而允许我们选择哪些类可用，哪些类不可用。 根据我们的工程师的说法，开销约为 10%——还不错。
除此之外，这可能也与您相关，在 Java 方面，我们使用 Acegi（现在的 Spring Security），并使用 AOP 对某个用户可以调用哪些方法进行基于角色的控制。 这对于授权来说非常有效。 因此，实际上，通过 JavaScript 访问我们的应用程序的用户首先拥有可用的受限 API，然后可以根据授权进一步限制该 API。 因此，您可以使用 AOP 技术来进一步限制可以调用哪些方法，从而允许在其他脚本语言中公开它，例如 Groovy 等。我们也在添加这些方法，相信我们的底层 Java API 保护用户免受未经授权的访问。
Disclaimer: I am not an expert on Java Security APIs, so there may be a better way to do this.
I work for Alfresco, Java-based Open Source Enterprise CMS, and we implemented something similar to what you describe. We wanted to allow scripting, but only to expose a subset of our Java APIs to the scripting engine.
We chose Rhino Engine for JavaScript scripting. It allows you to control which APIs are exposed to JavaScript, which allows us to choose which classes are available, and which are not. The overhead, according to our engineers, is on the order of 10%- not too bad.
In addition to this, and this may be relevant to you as well, on the Java side, we use Acegi (now Spring Security), and use AOP to give role-based control over which methods a certain user can call. That works pretty well for authorization. So in effect, a user accessing our app through JavaScript first has a restricted API available to him in the first place, and then that API can be restricted even further based on authorization. So you could use the AOP techniques to further restrict which methods can be called, thus allowing to expose this in other scripting languages, such as Groovy, etc. We are in the process of adding those as well, having the confidence that our underlying Java APIs protect users from unauthorized access.