5

我喜欢用于配置的“代码即数据”的想法,因为您从案例类中获得的验证与您想要对配置文件进行的验证相同。Twitter 编写了一个很好的 Eval 实用程序,使这变得容易(https://github.com/twitter/util)。我想允许用户将配置文件上传到远程服务。这开启了针对我的远程服务注入代码的可能性。

例如,如果我有以下配置案例类:

case class MyConfig(param1: String)

我希望用户能够上传包含命令的文件:

MyConfig(param1 = "My Param Value")

...但不是包含命令的文件:

MyConfig(param1 = {import someDangerousPackage; someDangerousCommand(); "My Param Value"})

有没有办法拦截编译以确保没有调用任何函数?

4

1 回答 1

0

人们可以在不导入包的情况下添加危险代码;发出 rm ... 命令需要多少行代码?

最好的解决方案是不要让人们发送代码进行配置;只需使用 XML 解析器或类似的东西。唯一真正安全的选择是自己解析上传并将其与允许使用的关键字(和引用的字符串)的严格白名单进行比较。至此,您已经完成了编写自己的解释器的一半,但仍然容易出错,因此解析文本文件开始看起来既是一种懒惰的选择,也是一种安全的选择。

于 2013-12-14T10:01:47.813 回答