中间件:使用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
你的主要安全需求是确保服务器不能通过任何机制(不仅仅是直接评估,还包括提供文件名)来评估客户端发送的任何内容。次要要求是它们也不应该有任何机制来生成允许其他客户端评估意外内容的消息(即避免 XSS 问题)。如果你能满足这些要求,你就有了一个安全的服务器,使用的语言并不重要;事实上,使用多种语言是一个好主意,因为这让你利用每种语言的优势。
另外,使用一个精心配置的防火墙、大量的权限限制、某种形式的 DMZ 代理系统来至少验证信息的基本语法合法性等也是一个好主意。这些都是好的实践。(配置服务时,目标是让服务器尽可能地提供想要的服务。)
在发送电子邮件时,还有一些需要注意的事情。特别是,你不希望成为垃圾邮件的传输媒介,因此你需要注意确保客户端输入不能构造任意电子邮件头,并且所发送的数据格式是不可执行的(或者数据以一种非恶意的方式构造)。限制发送频率也是一个好主意;除非你的网站非常受欢迎,否则你不应该在所有客户端上每秒钟发送超过几条消息。如果你只是发送到一组小地址(例如,到一个固定的联系地址),那么你可以放松这些限制一点(但仍需小心电子邮件头注入)。在所有情况下,通过专门的电子邮件处理服务器路由所有电子邮件,而不是自己进行路由,因为这样可以避免大量的配置麻烦。
- 如何在roblox studio中1:1导入真实世界的地形?
- 求解,lua_resume的第二次调用继续执行协程问题。
- 【上海普陀区】内向猫网络招募【Skynet游戏框架Lua后端程序员】
- SF爱好求教:如何用lua实现游戏内调用数据库函数实现账号密码注册?
- Lua实现网站后台开发
- LUA错误显式返回,社区常见的规约是怎么样的
- lua5.3下载库失败
- 请问如何实现文本框内容和某个网页搜索框内容连接,并把网页输出来的结果反馈到另外一个文本框上
- lua lanes多线程使用
- 一个kv数据库
- openresty 有没有比较轻量的 docker 镜像
- 想问一下,有大佬用过luacurl吗
- 在Lua执行过程中使用Load函数出现问题
- 为什么 neovim 里没有显示一些特殊字符?
- Lua比较两个表的值(不考虑键的顺序)
- 有个lua简单的项目,外包,有意者加微信 liuheng600456详谈,最好在成都
- 如何在 Visual Studio 2022 中运行 Lua 代码?
- addEventListener 返回 nil Lua
- Lua中获取用户配置主目录的跨平台方法
- 如何编写 Lua 模式将字符串(嵌套数组)转换为真正的数组?
首先,生产中使用C/Lua的一个缺点是找到能够开发这些语言的资源往往更加困难。C++和JavaScript程序员通常更容易找到。
在安全方面,关键在于使用领先的实践方法。安全是关于风险降低的,因此没有人能实现完美的安全,因此需要减轻风险。
以下是我的建议:
就像所有中间件一样,您需要使用经过硬化的服务器。这是第一步,如果使用任何平台都会被攻击,您将陷入困境。中间件不应该在DMZ中。
您希望将Lua代码存储在编译代码之外(否则将失去使用Lua的优势)。使存储尽可能安全。CHMOD很好,安全的数据库服务器更好。脚本存储越安全,系统越安全。
您可以加密Lua源代码-这是一个权衡,因为这使得获得易于更新和修改的优势有点困难。您可能需要实现解密脚本缓存以提高性能。
您的安全与最弱的链条一样强。如果您提供了通过外部访问修改Lua源代码的方式,则这将是一种攻击向量。如果可以,请避免这种设计。
您应该考虑进行更改管理检查。例如,系统中单独的一个位置存储每个Lua文件的校验和。然后,如果对脚本进行了未经授权的更改,您可以中止功能,直到缓解了安全漏洞。
除了我上面提到的缺点之外,我认为你的计划没有任何基本缺陷。如果可以帮助打造良好的中间件系统,那么这很好。只需尽量减轻适配期间脚本受到攻击的风险。
为了扩展Donal的评论-考虑到node的流行,我认为JavaScript现在是脚本化中间件的领先实践 。如果您能够处理学习一种新的脚本语言,那么考虑使用它是一个不错的选择,因为它非常受支持、受欢迎和具有丰富的工具。