中间件：使用C作为引擎，Lua作为适配器......这是不好的做法（安全风险）吗？
我是一名集成顾问，倾向于在业余时间使用 C 和 Lua，不幸的是这不是我的日常工作；-(
不管怎样，我倾向于相信 C 和 Lua 的混合对于许多“产品”开发来说是完美的。我目前有一个用纯 C 构建的“适配器引擎”，但希望将适配器代码实际移动到 Lua...
例如，在 Lua 中编写 EMAIL 适配器比在 C 中容易得多...但我喜欢“发动机转速为 C"...
但现在有安全风险的一个大问题是，用户可以将任何他或她想要的内容添加到生产中的 LUa 脚本中......显然我们可以 CHMOD 文件......但这真的安全吗
？这里是 C / Lua 组合....但现在我是否确实使用 CHAR* 将 Lua 代码嵌入到 C 应用程序中...或者我是否发出 lua_dofile？
的帮助？
谢谢Lynton
I am an integration consultant and tend to use C and Lua in my spare time, unfortunately it is not my day job ;-(
Anyway, I tend to believe that a mixture of C and Lua is perfect for many "product" developments. I currently have an "adapter engine" built in pure C, but would like to actually move the adapter code to Lua....
For example, coding an EMAIL adapter in Lua is far easier than in C...yet I like the "engine speed of C"....
But now there is the big question of security risk in that the user can potentially add whatever he or she wants to the LUa scripts in production.....obviously there we could CHMOD the files...but is that really secure?
Ideally I want the C / Lua combination here....but now do I literally imbed the Lua code in the C application with a CHAR*....or do I issue a lua_dofile??
Thanks for the help
Lynton
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，在生产中使用 C/Lua 的缺点之一是往往更难找到可以为这些语言进行开发的资源。 C++ 和 JavaScript 程序员通常更容易找到。
在安全性方面，关键是使用领先的实践。安全性就是降低风险，没有人能够实现完美的安全性，因此您需要降低风险。
以下是我的建议：
与所有中间件一样，您需要使用强化服务器。这是第一步，如果服务器使用任何平台受到损害，您就会遇到麻烦。中间件不应该位于 DMZ 中。
您希望将 Lua 代码存储在已编译代码的外部（否则您将失去使用 Lua 的优势。）确保该存储尽可能安全。 CHMOD 很好，安全的数据库服务器更好。脚本存储越安全，系统就越安全。
您可以加密 Lua 源代码 - 这是一种权衡，因为它使获得轻松更新和修改的优势变得更加困难。为了提高性能，您可能需要实现解密的脚本缓存。
您的安全性与您最薄弱的环节一样强大。如果您提供一种通过外部访问修改 Lua 源代码的方法，这将成为攻击媒介。如果可以的话，请避免这种设计。
您应该考虑进行变更管理检查。例如，系统中存储每个 Lua 文件的校验和的单独位置。然后，如果对脚本进行了未经授权的更改，您可以中止运行，直到安全漏洞得到缓解。
除了我上面提到的缺点之外，我认为你的计划没有任何根本性的缺陷。如果它可以帮助制作一个好的中间件系统，我会说去吧。只需尽可能降低适配器脚本遭到破坏的风险即可。
为了扩展 Donal 的评论 - 鉴于 node 的流行，我想说 JavaScript 是 目前脚本中间件的领先实践。如果您能够学习一门新的脚本语言，考虑到支持、流行度和可用的工具，我认为这将是一个好主意。
First, one of the drawbacks to using C/Lua in production is it tends to be harder to find resources who can develop for these languages. C++ and JavaScript programmers are typically easier to find.
In terms of security, the key here is to use leading practices. Security is about risk reduction, there is no expectation one can achieve perfect security so you need to mitigate risk.
Here are my suggestions:
As with all middleware you need to use a hardened server. This is the first step, if the server is compromised using any platform you are in trouble. Middleware should NOT be in the DMZ.
You want to store the Lua code external to the compiled code (otherwise you lose the advantage of using Lua.) Make that storage as secure as you can. CHMOD is good, a secure DB server is better. The more secure the script store the more secure the system.
You can encrypt the Lua source - this is a trade off since it makes it a little harder to gain the advantage of easy updates and modification. You will probably need to implement decrypted script caching for performance.
Your security is as strong as your weakest link. If you provide a way to modify the Lua source via external access this will be an attack vector. Avoid this design if you can.
You should consider putting in change management checks. For example a separate place in the system where a checksum for each Lua file is stored. Then if an un-authorized change is made to a script you can abort functioning till the security breach is mitigated.
Other than the drawback I mentioned above, I don't think there is anything fundamentally flawed in your plan. If it can aid in making a good middleware system I would say go for it. Just mitigate the risk of your adapter scripts getting compromised as much as possible.
To expand on Donal's comment - given the popularity of node I would say that JavaScript is the the leading practice in scripted middleware right now. If you can handle learning a new scripting language I would say it would be a good idea given the support, popularity, and tools available.
您在安全方面的主要要求是确保服务器无法通过任何机制评估客户端发送的任何内容（不仅仅是直接评估，还可以通过提供文件名）。一个较小的要求是，它们也不应该有任何机制来生成允许其他客户端评估意外事物的消息（即避免 XSS 问题）。如果您能够满足这些要求，那么您就拥有了一个安全的服务器，并且它所使用的语言并不重要；使用多种语言实际上是一个好主意，因为它可以让您充分利用每种语言的优点。
使用精心配置的防火墙、大量权限限制、某种 DMZ 代理系统来至少验证消息的基本语法合法性等也是一个好主意。这些都是很好的做法。 （旨在配置一些东西，以便服务器只能设法提供您想要提供的服务。）
发送电子邮件时，还有一些其他事情需要注意。特别是，您不想成为垃圾邮件的渠道，因此您需要注意确保不能从客户端输入构造任意电子邮件标头，并且您发送的数据格式是不可执行的（或者数据是以非邪恶的方式构建）。速率限制也是一个好主意；除非您的网站非常受欢迎，否则您不需要每秒向所有客户端发送多于几条消息。如果您只发送到一小部分地址（例如，发送到固定的联系地址），那么您可以稍微放松这些限制（但仍然要小心标头注入）。在所有情况下，请由专业电子邮件处理服务器路由所有电子邮件，而不是您自己进行路由，因为这可以避免很多配置困难。
Your primary requirement in terms of security is to ensure that the server cannot evaluate anything send by clients by any mechanism (not just direct evaluation, but also through supplying filenames). A lesser requirement is that they should also not have any mechanism to produce a message that allows other clients to evaluate unexpected things (i.e., avoid XSS trouble). If you can satisfy these requirements, you've got a safe server and the language(s) that it written in won't matter; using multiple languages is in fact a good idea as it lets you leverage the best of each.
It's also a good idea to use a carefully configured firewall, plenty of privilege restriction, some kind of DMZ proxy system to at least verify basic syntactic legality of messages, etc. These things are all just good practice. (Aim to configure things so the server can only just manage to do the service you want to provide.)
With sending email, there are a few other things to beware of. In particular, you do not want to be a conduit for spam, so you need to take care to ensure that arbitrary email headers cannot be constructed from client input and that the data formats you send out are non-executable (or that the data is constructed in a way that is non-evil). Rate limiting is also a good idea; unless your site is insanely popular, you shouldn't need to send more than a few messages a second across all clients. If you're ever sending only to a small set of addresses (e.g., to a fixed contact address) then you can relax these restrictions a bit (but still be careful of header injection). In all cases, route all email by a specialist email handling server instead of doing routing yourself as this avoids a whole lot of configuration difficulties.