中间件：使用C作为引擎，Lua作为适配器……这是一种糟糕的做法（安全风险）？

我是一名集成顾问，在业余时间倾向于使用C和Lua，不幸的是，这不是我的日常工作-(

无论如何，我倾向于相信C和Lua的混合对于许多“产品”开发来说是完美的。我目前有一个用纯C构建的“适配器引擎”，但实际上我想把适配器代码移到Lua

例如，用Lua编写电子邮件适配器比用C编写要容易得多…但是我喜欢“C的引擎速度”

但是现在有一个很大的安全风险问题，用户可以在生产中向LUa脚本添加他或她想要的任何内容……显然，我们可以在那里对文件进行CHMOD……但这真的安全吗

理想情况下，我希望在这里使用C/Lua组合…但现在我是在C应用程序中嵌入Lua代码并使用CHAR*…还是发布Lua\u dofile

谢谢你的帮助

---

<>林顿

< P>首先，在生产中使用C/LUA的缺点之一是，很难找到能够为这些语言开发的资源。C++和JavaScript程序员通常更容易找到。 就安全性而言，这里的关键是使用领先的实践。安全性是关于降低风险的，没有人期望能够实现完美的安全性，因此您需要降低风险

以下是我的建议：

• 与所有中间件一样，您需要使用加固的服务器。这是第一步，如果使用任何有问题的平台时服务器受到破坏，那么中间件不应位于DMZ中

• 您希望将Lua代码存储在编译代码的外部（否则您将失去使用Lua的优势）。尽可能确保存储的安全性。CHMOD很好，安全的DB服务器更好。脚本存储越安全，系统就越安全

• 您可以加密Lua源代码-这是一个折衷方案，因为它使您更难获得易于更新和修改的优势。您可能需要实现解密脚本缓存以提高性能

<>你的安全性和你最弱的链接一样强大。如果你提供一种通过外部访问来修改Lua源的方法，这将是一个攻击向量。如果你可以的话，请避免这个设计。
>P>您应该考虑进行变更管理检查。例如，在系统中单独存储每个LUA文件的校验和。如果对脚本进行未经授权的更改，则可以中止操作直到安全漏洞被减轻。

除了我上面提到的缺点之外，我不认为您的计划有任何根本性的缺陷。如果它能帮助创建一个好的中间件系统，我会说，去吧。只要尽可能降低适配器脚本被破坏的风险

---

---

进一步介绍Donal的评论-鉴于JavaScript的流行性，我认为JavaScript是目前脚本中间件领域的领先实践。如果您能够学习一种新的脚本语言，我认为这是一个好主意，因为它提供了支持、流行性和工具。

您的主要需求是f安全性是确保服务器无法评估客户端通过任何机制发送的任何内容（不仅是直接评估，还可以通过提供文件名）。较低的要求是，它们也不应该有任何机制来生成允许其他客户端评估意外内容的消息（即，避免XSS故障）。如果您能够满足这些要求，那么您就有了一个安全的服务器，并且它所使用的语言也无关紧要；使用多种语言实际上是一个好主意，因为它可以让您充分利用每种语言的优点

使用精心配置的防火墙、大量的权限限制、某种DMZ代理系统来至少验证消息的基本语法合法性等也是一个好主意。这些都是很好的做法。（目的是进行配置，使服务器只能够管理您要提供的服务。）

---

在发送电子邮件时，还需要注意一些其他事项。特别是，您不想成为垃圾邮件的传播渠道，因此您需要注意确保不能从客户端输入构建任意电子邮件标题，并且您发送的数据格式是不可执行的（或者以非邪恶的方式构建数据）。速率限制也是一个好主意；除非你的网站非常受欢迎，否则你不需要在所有客户端上每秒发送超过几条消息。如果你只发送到一小部分地址（例如，固定联系人地址），那么你可以稍微放宽这些限制（但仍要小心标头插入）。在所有情况下，通过专业的电子邮件处理服务器路由所有电子邮件，而不是自己路由，因为这样可以避免大量的配置困难。

服务器端JS没有那么常见。@DonalFellows我相信我说过JS程序员比Lua程序员更常见，不是吗？服务器端Lua中间件比服务器端更不常见side JSI很惊讶Lua在这方面没有产生太大的影响。如果是这样的话，最好还是推荐Ruby。还有相当多的人在做服务器端Python、Perl和Tcl。没错，谁能解释程序员变化无常的天性。node的优势是异步无阻塞，可以提供良好的性能。（有一些可伸缩性声明——但这仍有待观察）答案很好，但我对第一段提出质疑。它忽略了外部影响——如果脚本存储在明文中，则会增加在系统外部访问它们的风险（例如操作系统零日缺陷）。在设计系统以降低风险时，应考虑到这一点。@Hogan：您使用DMZ系统的原因是通过将暴露设置减少到支持的协议中语法正确的消息来停止0天操作系统问题