最近披露的 Rails SQL 注入漏洞引起了人们的极大关注。我不擅长处理安全问题,所以我很紧张。我听说 MongoDB 不容易受到这种攻击。
这是永久迁移到 MongoDB 的好理由吗?
最近披露的 Rails SQL 注入漏洞引起了人们的极大关注。我不擅长处理安全问题,所以我很紧张。我听说 MongoDB 不容易受到这种攻击。
这是永久迁移到 MongoDB 的好理由吗?
不,仅仅因为 SQL 数据库容易受到 SQL 注入攻击,并不是迁移到 MongoDB 的好理由。
MongoDB 在某些用例中非常有用,特别是在您需要无模式集合的情况下。
如果您需要存储关系数据,关系数据库将为您提供更好的服务。
简而言之,如果您害怕 SQL 注入,请学习如何清理您的输入。不要迁移到 MongoDB。
新发现的漏洞不会影响所有人。阅读此处了解更多详情。
SQL 注入是一个已知数十年且广为人知的问题。当您遵守它们时,有一些编码实践使 SQL 注入完全不可能:
始终至少使用其中一种做法,您不必害怕 SQL 注入。
另一方面,MongoDB 是一项相当新的技术。目前尚不清楚哪种新手错误将是最典型的导致易受攻击的应用程序。也许有些事情就像 SQL 注入一样糟糕,每个人现在都在做却没有意识到。也许这个漏洞已经在黑帽黑客之间流传了。谁知道?
此外,正如 CodeGnome 所指出的,MongoDB 并不是 SQL 数据库的直接替代品。它有一个完全不同的哲学。这里 83% 的 MongoDB 问题是由尝试将 MongoDB 当作关系数据库来使用的人提出的,他们想知道为什么它不起作用。
使用 SQL 的关系数据库不是 NoSQL 的逐个功能替代品。根据您的问题领域,您有时可以做出不同的体系结构或设计决策,偏向于另一个,但您不能像备件一样简单地将它们换掉,因为它们具有非常不同的设计目标和性能特征。
软件安全是一个很大的话题,并且远远超出了 SO 问题的范围。但是,从广泛使用并快速修补的产品切换到您不了解的产品本质上并不是一个良好的风险管理权衡。
事实上,您所指的漏洞是一个Rails漏洞,该漏洞已被修补;你有零保证将来不会有其他 Ruby 或 Rails 漏洞——或者,事实上,网络或操作系统漏洞——针对 MVC 或操作系统堆栈的不同部分。因此,我不确定你认为从风险管理的角度来看,将 SQL 描绘成这个故事中固有的恶棍会得到什么。