c - 中间件:使用 C 作为引擎，Lua 作为适配器……这是不好的做法(安全风险)吗？

Question

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

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

例如，在 Lua 中编写 EMAIL 适配器比在 C 中容易得多...但我喜欢“C 的引擎速度”...

但现在存在安全风险的大问题，因为用户可能会在生产中将他或她想要的任何内容添加到 LUa 脚本中......显然我们可以 CHMOD 文件......但那真的是这样吗安全吗？

理想情况下，我想要 C/Lua 组合……但现在我是将 Lua 代码直接嵌入到 C 应用程序中并使用 CHAR* ……还是发出 lua_dofile？？

感谢帮助

林顿

Answer 1

首先，在生产中使用 C/Lua 的缺点之一是往往更难找到可以为这些语言开发的资源。 C++ 和 JavaScript 程序员通常更容易找到。

在安全方面，这里的关键是使用领先的做法。安全是为了降低风险，没有人能期望实现完美的安全，因此您需要降低风险。

以下是我的建议:

• 与所有中间件一样，您需要使用强化服务器。这是第一步，如果使用任何平台破坏服务器，您就有麻烦了。中间件不应位于 DMZ 中。

• 您想将 Lua 代码存储在编译后的代码之外(否则您将失去使用 Lua 的优势。)尽可能确保存储安全。 CHMOD 很好，安全的数据库服务器更好。脚本存储越安全，系统就越安全。

• 您可以加密 Lua 源代码 - 这是一种权衡，因为它更难获得轻松更新和修改的优势。您可能需要为性能实现解密脚本缓存。

• 您的安全性与您最薄弱的环节一样强大。如果您提供一种通过外部访问修改 Lua 源代码的方法，这将是一个攻击 vector 。如果可以，请避免这种设计。

• 您应该考虑进行变更管理检查。例如，系统中存储每个 Lua 文件的校验和的单独位置。然后，如果对脚本进行了未经授权的更改，您可以中止运行，直到安全漏洞得到缓解。

除了我上面提到的缺点，我认为你的计划没有任何根本性的缺陷。如果它可以帮助制作一个好的中间件系统，我会说去做吧。尽可能降低适配器脚本遭到破坏的风险。

---

扩展 Donal 的评论 - 考虑到 node 的受欢迎程度我会说 JavaScript 是目前脚本化中间件的领先实践。如果您可以学习一种新的脚本语言，我会说考虑到支持、受欢迎程度和可用工具，这将是一个好主意。