中间件:使用C作为引擎,Lua用于适配器...这种做法是否存在安全风险?

我是一名集成顾问,闲暇时候喜欢使用 C 和 Lua,但不幸的是这不是我的工作日常工作;-(

无论如何,我倾向于相信在许多“产品”开发中,将 C 和 Lua 混合使用是完美的。我目前有一个使用纯 C 构建的“适配器引擎”,但是想将适配器代码实际移动到 Lua 中……

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

但现在有一个很大的安全风险问题,即用户可能会向生产中的 Lua 脚本添加任何他或她想要的内容…..显然,我们可以 CHMOD 文件…..但这真的安全吗?

理想情况下,我希望在这里使用 C/Lua 组合....但我现在应该在 C 应用程序中使用 CHAR* 嵌入 Lua 代码....还是应该发出 lua_dofile ??

谢谢帮忙

Lynton

原文链接 https://stackoverflow.com/questions/8018934

点赞
stackoverflow用户215752
stackoverflow用户215752

首先,生产中使用C/Lua的一个缺点是找到能够开发这些语言的资源往往更加困难。C++和JavaScript程序员通常更容易找到。

在安全方面,关键在于使用领先的实践方法。安全是关于风险降低的,因此没有人能实现完美的安全,因此需要减轻风险。

以下是我的建议:

  • 就像所有中间件一样,您需要使用经过硬化的服务器。这是第一步,如果使用任何平台都会被攻击,您将陷入困境。中间件不应该在DMZ中。

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

  • 您可以加密Lua源代码-这是一个权衡,因为这使得获得易于更新和修改的优势有点困难。您可能需要实现解密脚本缓存以提高性能。

  • 您的安全与最弱的链条一样强。如果您提供了通过外部访问修改Lua源代码的方式,则这将是一种攻击向量。如果可以,请避免这种设计。

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

除了我上面提到的缺点之外,我认为你的计划没有任何基本缺陷。如果可以帮助打造良好的中间件系统,那么这很好。只需尽量减轻适配期间脚本受到攻击的风险。


为了扩展Donal的评论-考虑到node的流行,我认为JavaScript现在是脚本化中间件的领先实践 。如果您能够处理学习一种新的脚本语言,那么考虑使用它是一个不错的选择,因为它非常受支持、受欢迎和具有丰富的工具。

2011-11-05 10:04:30
stackoverflow用户301832
stackoverflow用户301832

你的主要安全需求是确保服务器不能通过任何机制(不仅仅是直接评估,还包括提供文件名)来评估客户端发送的任何内容。次要要求是它们也不应该有任何机制来生成允许其他客户端评估意外内容的消息(即避免 XSS 问题)。如果你能满足这些要求,你就有了一个安全的服务器,使用的语言并不重要;事实上,使用多种语言是一个好主意,因为这让你利用每种语言的优势。

另外,使用一个精心配置的防火墙、大量的权限限制、某种形式的 DMZ 代理系统来至少验证信息的基本语法合法性等也是一个好主意。这些都是好的实践。(配置服务时,目标是让服务器尽可能地提供想要的服务。)

在发送电子邮件时,还有一些需要注意的事情。特别是,你不希望成为垃圾邮件的传输媒介,因此你需要注意确保客户端输入不能构造任意电子邮件头,并且所发送的数据格式是不可执行的(或者数据以一种非恶意的方式构造)。限制发送频率也是一个好主意;除非你的网站非常受欢迎,否则你不应该在所有客户端上每秒钟发送超过几条消息。如果你只是发送到一组小地址(例如,到一个固定的联系地址),那么你可以放松这些限制一点(但仍需小心电子邮件头注入)。在所有情况下,通过专门的电子邮件处理服务器路由所有电子邮件,而不是自己进行路由,因为这样可以避免大量的配置麻烦。

2011-11-05 10:38:29