假设我有一个用 Java 编写的现有应用程序，我希望向其添加脚本支持。这对于 Groovy 来说是相当微不足道的(在 .Net 中对于任何 Iron 系列的动态语言也是微不足道的)。
尽管添加支持是微不足道的，但它引发了一系列关于脚本执行和安全性的问题 - 以及如何实现该安全性。
有没有人遇到任何有趣的文章/论文或对此有任何见解并希望与大家分享？特别是我对诸如执行上下文、脚本身份验证、脚本签名等架构方面的事情非常感兴趣……你知道，那种阻止用户运行他们刚好下载的任意脚本的东西搞砸他们的整个应用程序，同时仍然允许脚本有用和灵活。
快速编辑
我提到签名和身份验证是不同的实体，因为我将它们视为安全的不同方面。
例如，作为应用程序的开发者/供应商，我分发了一个签名脚本。该脚本在设计上具有合法的“数据破坏性”。就其本质而言，它只能由管理员运行，因此绝大多数用户/系统进程都不能运行它。在我看来，根据脚本执行的操作以及运行该脚本的人员，需要某种安全/身份验证上下文。
最佳答案
script signing
从概念上讲，这只是进入您的加密工具箱并使用现有的工具。让人们签署他们的代码，在下载时验证签名，并检查签名的发起者是否可信。
困难的(呃)问题是什么使人们值得信任，以及谁可以选择这一点。除非您的用户是技术人员，否则他们不想考虑这一点，因此他们不会制定好的政策。另一方面，您可能必须让用户引入信任[除非您想要一个 iPhone AppStore 风格的围墙花园，这听起来不像]。
script authentication
这与签名有何不同？或者，您的问题只是:“我应该在这里考虑哪些概念”？
真正的问题当然是:您希望您的用户免受什么侵害？它只是在传输中修改，还是您还想对脚本的行为做出保证？一些示例可能是:脚本无法访问文件系统、脚本只能访问文件系统的特定子树、脚本无法访问网络等。
我认为，如果脚本是在 haskell 中完成的并且 IO monad 被分解成更小的部分，那么 [只需少量工作] 就可以提供一些关于脚本如何访问外部世界的保证。或者，如果您让脚本在它们自己的不透明 monad 中运行，并且可以访问 IO 的有限部分，则可能。请务必删除对不安全函数的访问权限。
您可能还想查看 Java(小程序)安全模型中的注意事项。
我希望这能给你一些思考。
关于java - 向应用程序添加脚本安全性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/476640/