【问题标题】:Adding scripting security to an application向应用程序添加脚本安全性
【发布时间】:2010-10-03 08:41:12
【问题描述】:

假设我有一个用 Java 编写的现有应用程序,我希望添加脚本支持。这对于 Groovy 来说是相当简单的(在 .Net 中对于任何 Iron 系列动态语言来说都是微不足道的)。

尽管添加支持微不足道,但它引发了一系列关于脚本执行和安全性以及如何实现该安全性的问题。

有没有人遇到过任何有趣的文章/论文或对此有任何见解想分享?特别是,我会对诸如执行上下文、脚本身份验证、脚本签名等架构方面的东西非常感兴趣......你知道,那种阻止用户运行他们刚刚下载的任意脚本的东西搞砸了他们的整个应用程序,同时仍然让脚本变得有用和灵活。

快速编辑

我将签名和身份验证视为不同的实体,因为我将它们视为安全的不同方面。

例如,作为应用程序的开发人员/供应商,我分发了一个签名脚本。该脚本在设计上具有合法的“数据破坏性”。就其本质而言,它只能由管理员运行,因此绝大多数用户/系统进程不应该能够运行它。在这种情况下,在我看来,根据脚本执行的操作和运行该脚本的人员,需要某种安全/身份验证上下文。

【问题讨论】:

    标签: java security architecture groovy scripting


    【解决方案1】:

    脚本签名

    从概念上讲,这只是进入您的加密工具箱并使用现有工具。让人们签署他们的代码,在下载时验证签名,并检查签名的发起者是否受信任。

    困难的(呃)问题是什么使人们值得信任,以及谁可以选择信任。除非您的用户是技术人员,否则他们不想考虑这一点,因此他们不会制定好的政策。另一方面,您可能必须让用户引入信任 [除非您想使用 iPhone AppStore 风格的围墙花园,这听起来不像]。

    脚本认证

    这与签名有何不同?或者,您的问题仅仅是:“我应该在这里考虑哪些概念”?

    真正的问题当然是:您希望您的用户受到什么保护?仅仅是在途修改,还是您还想对脚本的行为做出保证?一些示例可能是:脚本无法访问文件系统、脚本只能访问文件系统的特定子树、脚本无法访问网络等。

    我认为,如果脚本在 haskell 中完成并且 IO monad 被分解成更小的部分,我认为 [通过少量工作] 可以提供一些关于脚本如何访问外部世界的保证。或者,如果您让脚本在它们自己的不透明 monad 中运行,并且可以访问 IO 的有限部分,则可能。请务必移除对不安全功能的访问权限。

    您可能还想查看 Java(小程序)安全模型中的注意事项。

    我希望这能让你有所思考。

    【讨论】:

    • 我认为重用 java applet 安全模型是一个好的开始。
    【解决方案2】:

    您可以查看有关安全性的文档: http://groovy.codehaus.org/Security 基本上,您可以使用通常的 Java 安全管理器。

    除此之外,还有一个示例应用程序展示了如何通过在编译时分析其 AST(抽象语法树)来内省代码,以便您可以允许/禁止某些代码构造等。这是一个示例算术外壳显示了这一点: http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/examples/groovyShell

    【讨论】:

      猜你喜欢
      • 2010-09-05
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-04-09
      • 1970-01-01
      • 1970-01-01
      • 2017-05-23
      相关资源
      最近更新 更多