Lisp 应用程序和 web 应用程序是否需要特殊的输入清理？答案

【问题标题】：Do Lisp apps and webapps need special input sanitizing?Lisp 应用程序和 web 应用程序是否需要特殊的输入清理？
【发布时间】：2011-10-27 03:01:49
【问题描述】：

编辑 3 自从我提出这个问题以来，已经发生了相当多的新进展。基本上我没有“看到东西”，并且发现用 Clojure 编写的 web 应用程序容易受到攻击，这促使 Clojure 1.5 发生了变化，并且非常在 Clojure Google 群组上进行了激烈的讨论。

以下是 Hacker News 上某人关于 Clojure 1.5 变化的引述：

另一个稍微有趣的事情是突然增强读取评估和 EDN[2]。这主要是因为恶劣的天气 Ruby/Rubygems 存在 YAML 漏洞，这导致了激烈的讨论 Clojure 阅读器在默认情况下应该如何操作。

漏洞已被发现，现在修复 Clojure 为时已晚，因此 read-eval 仍应默认设置为 true （否则它会破坏太多事物）。在 Clojure 中解析输入的任何人都不应使用默认读取函数，而应使用 EDN 函数。

所以我当然没有看到任何东西，人们很快（甚至不到 18 个月）就找到了攻击常见 Clojure webapp 堆栈的方法。

编辑 2 我不知道，但我的问题是以下问题的欺骗（被描述为“杀手问题”）：Lisp data security/validation

如果有人对这个问题的答案感兴趣，我建议他们打开上面的问题并阅读 Lisp 大师在那里做出的答案，而不是 “这里没什么可看的，继续前进，就像 PHP 或 JavaScript".

编辑：我想知道，由于它是 Lisp，攻击者是否会“更容易”转换“数据”（即“使用恶意软件制作的用户输入意图”）转化为“代码”。例如，在开始“评估”/解析或任何数据之前，我是否需要转义/替换用户输入中的所有括号？

原始问题

我仍在阅读有关 Lisp 的信息，突然间我想知道，对于整个“代码就是数据”/“数据就是代码”的事情，Lisp 是否需要执行输入清理以防止攻击？

我专门考虑 web 应用程序，比如当用户执行一些 HTTP POST 时。

如果他发送的数据包含以下内容怎么办：

This is some malicious (eval '(nasty-stuff (...)) or whatever.

（我不是 Lisp 程序员，这只是我脑海中的一个例子，并不意味着实际上是卑鄙的代码）

由于 Lisp 的工作方式，有什么特别需要记住的吗？例如，如果某个阴暗面的黑客知道某个网络服务器正在 Clojure 上运行，他是否可以利用这一事实，然后注入“括号之间的代码”，然后在网络服务器上进行评估？

在从 Lisp 接收/解析用户数据（因此可能是精心制作的数据）时，这是否是一个问题？

【问题讨论】：

“Easier”在谈论漏洞利用时相对没有意义。正如 ObscureRobot 正确指出的那样，怀疑一切或更好的是仍然不要 eval 用户输入。正如 Robot 所指出的那样，LISP 并不是特别特别。
几乎没有任何理由在生产代码中使用 eval，除非您提供在线评估器。
@ObscureRobot：欺骗：stackoverflow.com/questions/3000193
我看不出它与任何其他具有 EVAL 的语言有何不同。你说在另一个问题上去阅读“Lisp 大师”，但他们说的完全一样，即永远不要使用 EVAL。 :-)

【解决方案1】：

我已经用 Lisp（即 Common Lisp）编写了一些网络应用程序，以下是我牢记在心的事情：

如果您使用read，对于任何不受信任的数据，您应该始终将*read-eval* 设置为nil
如果你正在处理代码生成——例如，HTML、JS、CSS 或 SQL 生成——这在 Lisp 领域很常见，你不应该忘记使用相应库提供的清理工具（不要使用原始输入字符串）

基本上就是这样。此外，由于它是 Lisp，它通常会使您的系统不易受到攻击，因为：

【讨论】：

我接受这一点，并建议那些寻求更好答案的人在这里查看被骗者（我的问题是被骗者）：stackoverflow.com/questions/3000193 这是完全相同的问题.. .

【解决方案2】：

您应该始终假设注入攻击是可能的，除非另有证明。如果不详细了解您的特定 Lisp 环境以及与之比较的内容，就无法回答您是否需要“特殊”清理。

请注意，“代码”和“数据”之间的软屏障并不是 Lisp 独有的。 perl，曾经是网络世界的主力有eval。所以does PHP。看起来 Java 字节码注入也是可能的。

【讨论】：

@Cedric Martin，您可能需要在这个问题上多做一些工作，而不是对问题的有效答案投反对票。您的新编辑更多地解释了您的意思。
我熟悉 Lisp，但这没关系。是的，在将数据视为代码时，Lisp 非常宽容，但它并不是独一无二的。清理您的数据！
@Cedric Martin，这一切都取决于您对数据做什么。如果你将它转义并插入到数据库中，那么它显然不会被执行。如果逐字显示，则取决于显示它的引擎的工作方式。如果它自己不进行任何转义，那么它可能会被执行。看看引擎是如何工作的。
也许我在上面说“特殊”消毒时太迂腐了。当然，您希望转义用户输入以确保它不会被解释。你可能想做一些事情，比如寻找不平衡的括号并禁止这样的输入。但是我认为这些任务与您在编写 perl/Mason 或 PHP 时对输入进行的那种清理工作是同构的。或者任何东西，真的。
@Radu，作为一个 Lisp 用户，这个答案完美地解决了这个问题 - 无论语言如何，未经处理的输入都会并且将会造成严重破坏。 Lisp 的代码作为数据范式没有任何改变——你不应该是eval-ing 用户输入。

【解决方案3】：

确实可以归结为：不要使用 READ 也不要使用 EVAL。您需要确切地知道要发送到其中一个或两个函数的内容，以及执行它们的上下文。如果您不调用其中任何一个，那么您就可以了。

【讨论】：