SQL注入已有17年的历史。为什么它仍然存在？

#1 楼

没有针对SQLi的常规修补程序，因为没有针对人类愚蠢的修补程序。已经建立了既易于使用又可解决问题（特别是参数绑定）的技术，但是仍然必须使用这些技术。许多开发人员根本不了解安全问题。大多数人担心应用程序根本不会运行，也不在乎安全性，特别是如果它使事情（甚至略微）变得更加复杂，并带来测试之类的额外费用。

这类问题不仅限于SQLi，而是在缓冲区溢出，证书检查，XSS，CSRF ...中发现的。由于需要额外的测试和开发人员所需的额外专业知识，因此进行安全编程的成本更高。只要市场更喜欢便宜的产品，并且对安全性不怎么在意，您就会获得便宜且不安全的解决方案。尽管设计安全性在很大程度上有助于改善安全性，但开发人员经常会因为无法理解设计而以其自身的方式来解决该设计问题。

#2 楼

因为这不是问题。



上一次出现SQL注入漏洞的公司何时被告上法庭，并因re顾用户数据而遭到巨额罚款，董事是否因疏忽而被警告，罚款或锁定？专业机构的合格监管者/审计师必须批准并签署面向公众的计算机系统，然后才能投入使用？用防火材料，警报器和良好的逃生路线建造建筑物。不是。我们引入了强制使用不易燃建筑材料，带有火灾中断的防火设计，火灾警报器的法规。设计。不是。事实并非如此。我们必须制定法规，要求合格的工程师批准建筑设计，并针对特定用途进行设计和建造，一旦出现故障，社会就会将工程师告上法庭。人们将死”将是使食品加工清洁安全的足够充分的理由，但事实并非如此。在一个完全不受监管的行业中。

即使是关心它的公司，它们也不能有效地宣传“我们代码中没有已知的SQL注入漏洞”作为任何人都在乎的营销重点。客户问销售人员的问题不是那种。对于他们来说，这不是竞争优势，而是成本，开销。对其进行防护可降低它们的竞争力，降低移动速度，并为相同的功能执行更多的工作。

激励措施都是为了保持生存状态。因此，它一直存在。

使SQL注入成为公司的问题，它们将使它消失。您是否使用Cookie。他们做到了。因此，对面向公众的计算机系统进行监管以使它们更烦人可以生效-即使当前的监管非常无用。

#3 楼

SQL注入仍然存在，因为软件界仍然不了解，应通过将语法树构造为一等对象来完成树结构化值（如查询或标记）的编程生成，而不是通过串联表示a片段的字符串

近年来，随着诸如LINQ to SQL或SQLAlchemy之类的查询生成器工具的可用性不断提高，已经有了一些进步，但这只是在编程语言方面。关系数据库仍然没有提供一种标准的，引人注目的替代接口，该接口根本不是基于以字符串形式发送查询。查询的结构（连接哪些表，过滤条件，要投影的列）是固定的。当您有一个需要在运行时构造查询文本的应用程序时，使用准备好的查询参数会很麻烦。

因此，如果可以构建一个标准的，非文本的，树状结构的协议来描述查询并将其传达给数据库，并且设计成比文本查询更易于使用，则可以解决从长远来看这个问题。但是，直到行业采用阻力最小的路径是安全的方法后，问题才会消失。只要我们坚持不安全的默认安全系统，在这些系统上编写安全代码会花费不必要的精力，那么问题就出在我们身上。 （请考虑一下在内存管理的语言中根本不存在的所有缓冲区溢出！）


请注意，与SQL注入相同的根本问题困扰着Web，即跨站点脚本的名称-实际上这只是将JavaScript注入动态HTML页面。 Javascript程序员是一个非常常见的模式，他们没有通过将DOM当作对象树来使用DOM，而是使用innerHTML属性将其设置为由简单字符串连接构建的HTML文本。如果没有将innerHTML属性放入浏览器的DOM实现中，则将永远不会存在许多XSS漏洞。


此外，对于那些还没有看过Tony Hoare关于空指针的演讲的人来说，它同时是正交的（空指针，而不是SQL注入），但是与此同时却非常相关：



Tony Hoare，“空引用：十亿美元的错误”。

#4 楼

测试时，很容易测试您期望发生的事情。例如，当在数据库中填写“名称”字段时，您可能会选择一些自己熟悉的东西，例如“ John Doe”。这样可以正常工作，并且您的应用程序似乎可以正常运行。 />当然，您不会对应用程序的名称进行测试，因此，在您进行的所有测试中，此类名称都会暴露出安全隐患。安全声明

很容易证明存在安全漏洞（您只需要测试上述名称即可）。也很容易证明一个特定的孔已被修复。很难证明没有其他安全漏洞。

#5 楼

Steffen的回答很不错，但我想补充一下。我认为原因可以细分为以下主题：


缺乏知识或对开发人员的教育
在企业开发环境中搅动
提前交付
从顶部开始对安全性的重视不足

所以让我们分解一下。

开发人员培训

有一个这些天非常重视用户教育。教用户如何维护强密码。教用户如何识别网络钓鱼。教用户如何...。您明白了。有些企业可能很多，但是我只能说自己的专业经验，而且我没有在很多企业工作过；），确实有培训计划。但是这些培训计划可能不完整，或者达不到所需知识的深度。这并不是要贬低构建这些程序的辛苦工作。但是要说，就像在学校环境中一样，不同的人学习的方式也不同。而且，除非您有针对开发人员的继续教育计划，否则将很难传达“使用参数化查询，这是在PHP，Java，Python，Ruby，Scala，NodeJS等中的实现方式”。有效地吸引受众的开发，交付和维护开发人员程序是艰苦的工作。

开发人员流失

上面，我提到的一件事是针对不同的学习类型有效地吸引受众。原因之一是许多企业对开发人员的流失率很高，因为开发人员是承包商，他们在不同公司的项目之间转移。而且公司的安全性并不总是相同的。一个公司可能根本没有一个安全程序，而另一个公司可能有一个出色的安全程序，开发人员突然被新的信息轰炸，在他们搬到另一家公司之前的六个月中，都需要他们提供这些信息。真可惜，但它确实发生了。不幸的是，完成项目的最快途径通常是不通过安全控制来完成项目。它以仍然无法解决的最坏的方式完成它。我们知道，当需要维护项目和解决问题时，它将导致更多的工作，更多的时间和更多的资金，但是管理层只是希望项目退出。

我提到的另一个项目正在为众多编程语言开发安全培训计划。许多企业没有一两种语言。因此，开发人员喜欢（或鼓励）尝试新的功能。其中包括语言和框架。这意味着安全程序必须不断发展。

管理支持

在这里，我们在管理层。每次，似乎是在一次公共违规事件中，都有本可以实施的控制措施，这些控制措施并不难，但是却被遗漏了。尽管上课后又下课，但总是首先推动交付产品而第二次担心总是回到产品公司。管理人员必须从头开始推动，以便在开始时花时间建立安全性。他们必须了解，将花费更多的工作，更多的时间和更多的金钱来解决问题，维护产品和支付罚款。但是，成本效益分析指出的问题是产品交付，而不是罚款或所需的维护工作。这些方程式必须改变，这在一定程度上要归功于MBA级别的教育（低迷，整个圈子）。必须告诉业务经理，要在不断增加的违规情况下取得成功，安全必须放在首位和居中。岁，有很多原因。作为安全从业人员，我们只能做很多事情来教育和提高人们对在安全性不被视为SDLC的组成部分时发生的情况的认识。

#6 楼

我同意很多答案，但是没有提出一个非常重要的观点：代码并不能神奇地修复自身，并且有很多已经使用了17年的代码。我已经看到许多公司编写了干净且安全的新代码，而在某些较旧的部分中该应用程序仍可能受到攻击。最糟糕的是：修复旧代码很昂贵，因为它要求开发人员深入研究在不同时代以不同的编码风格和技术编写的代码。有时，修复旧代码以免导致SQL注入需要一个人重新创建当天买回来的整个库（这是我几年前必须要做的事情）。新代码没有SQL注入，但是在过去的4到5年中，我个人还没有看到任何专业编写的新代码。 （唯一的例外是，开发人员必须对旧代码进行快速而肮脏的修复，并使用与其余代码相同的样式/技术。）

#7 楼

我相信这是因为许多开发人员仅出于“完成”的价值而学到了足够的知识来完成工作。他们通常从过时的在线教程中学习如何构建SQL代码，然后在代码“工作”到可以说“我可以将东西放入数据库中并生成结果页面”的程度时，他们很满意。

考虑这个在梯子上的家伙：他为什么没有适当的脚手架？因为他正在完成工作。将梯子靠在楼梯上的墙上，这样就可以了。直到没有。

与INSERT INTO users VALUES($_POST['user'])相同。它工作正常。直到没有。

另一件事是他们不了解危险。当那个家伙坐在不稳定的梯子上时，我们了解重力和跌落。通过从未经验证的外部数据构建S​​QL语句，他们不知道该怎么做。听说过SQL注入。

#8 楼

我认为主要原因是开发人员培训不是从最佳实践开始的，而是从理解语言开始的。因此，新程序员以为他们已经接受过使用工具来创建某些东西的培训，因此可以按照他们的教学方式来创建查询。下一步也是最危险的步骤是允许某人在不进行审查的情况下做出任何事情，因此有继续的机会做出更多错误的选择，而又不知道问题出在哪里，并养成无视整个行业公认的最佳做法的习惯。因此，总而言之-训练有素的程序员在一种环境下工作，该环境除了最终产品外没有其他价值。

它与智力或“人类愚蠢”无关。多年来，已经有一种系统的方法已被很好地定义，对于以更快或更便宜的实现为名，生产软件的任何人都忽略了该过程是一种疏忽。也许有一天，这种行为的法律后果将使我们能够采取更多的控制措施，例如医疗或建筑行业，否则，如果不遵守这些规则和公认的做法，将会导致失去执照或其他处罚。

#9 楼

为什么SQL注入漏洞尚未消失？隐喻地讲，出于同样的原因，自1895年首辆汽车出现碰撞事故以来，甚至是当今最具创新性和现代性的自动驾驶汽车，特斯拉S型（自动驾驶）或Google自动驾驶汽车碰撞事故时有发生。时间。

汽车是由人类创造（和控制）的，人类会犯错。当某些东西是安全的但实际上引入了新的漏洞（例如，由于开发补丁的时间/预算有限，或者开发人员有漏洞）时，他们往往会在安全性设计中犯严重的错误，或者倾向于用“快速修复”来破坏事物。他写此修复程序时遇到了很大的麻烦。

总是由开发人员引起的吗？从本质上讲是肯定的，但一线开发人员并非总是如此。例如，当地一家超级市场要求网络开发公司为其创建网站。开发人员从托管公司租用一些共享的托管空间来托管站点，并安装WordPress和一些有用的插件。

现在，Web开发公司的开发人员不必为了引入易受攻击性而引入SQL注入漏洞。这里可能出什么问题？以下是一些示例：


托管公司未更新到最新的PHP版本，而使用过的PHP版本通常容易受到SQLi攻击。配置了一些公共的附加软件，例如phpMyAdmin，并且没有对其进行更新。容易受到SQLi的攻击。<​​br />
现在提出的问题是谁负责？夸张地说，是超市，Web开发公司，托管公司，WordPress社区，WordPress插件开发人员还是滥用漏洞的攻击者？ -这不是陈述，是夸张的，只是出现一些问题时可能会提出的一些问题。风险因素，因为某些开发人员倾向于具有“那不是我的代码”的态度。您可以想象有时候造成这种情况的复杂程度。

#10 楼

首先，没有人正确地写出安全要求，他们说“产品应该是安全的”，这绝不是可测试的。所有这些人都可能拥有大学学位，并且一直在解决我们甚至没有开始关注的问题...问题是，他们从未被教导过如何安全地开发软件。首先是在学校，然后是大学，然后是他们从事的任何工作，其中的任何培训都是“在职”的，因为软件公司太害怕培训万一离开的开发人员。

同样，在更少的时间内完成更多工作的压力也越来越大，他们正忙于解决一个问题并继续解决下一个问题，随着下一个问题的到来，他们几乎没有时间进行反思。测试超出他们正在开发的内容的范围，如果发现问题，则很可能是开发人员要解决的问题。开发人员的口号是“不要测试您不准备解决的问题”

第三，出于与软件开发人员相同的原因，测试人员也没有受过培训来发现安全漏洞，实际上，很多测试（以我的观点）只是重复开发团队的测试。第四，上市时间是一个很大的因素，如果您首先去那里就可以赚钱，可以看到安全地发展对发展速度有重大影响-我的意思是说，谁有时间建立威胁模型！ ;）

最后不只是SQL注入，自1960年代以来就已经知道缓冲区溢出，并且您仍然可以以惊人的规律性偶然发现它们。

#11 楼

是的，在人类学上，人类是愚蠢的。

是的，从政治上讲，激励结构不能充分惩罚易受攻击的应用程序

是的，该过程有缺陷-代码编写很急；坏/旧的代码并不总是会被丢弃。

是的，从技术上讲，默认情况下，将数据作为代码进行处理和混合比较困难。

但是，有一个更积极的观点（让我们忽略上面答案解释的99％的SQLi漏洞）。因为我们很棒，所以SQLi仍然存在于经过精心设计和精心开发的网站上。黑客统治。您只需查看过去十七年来为恢复对人类的某种信念而开发的数百种攻击媒介和数千种SQLi有效负载。每年都会带来DEFCON / BlackHat / RSA / IEEESSP提出的新技术。 Facebook，Google和类似公司的漏洞赏金计划都必须为关键的SQLi至少淘汰一次。

部分原因是由于我们系统中的复杂性和层数，每个层都以更新和更有趣的方式对数据进行变异。我们越来越需要使用更少的资源来做更多的事情，更快。而且，只要我们无法切实地测试进入系统的所有路径，就没有人会证明对注射问题的解决方案。

#12 楼

因为在大多数3年的教育周期和同等学习中都没有涉及此类安全问题，所以许多开发人员（包括我本人）都遵循了这种做法。考虑到领域的广泛性，实际上3年甚至不足以应付实际的学习计划。因此，诸如安全性之类的东西被放弃了。永远不会尝试自己学习新事物，这些人总是会编写容易产生SQLi的代码，直到受过良好教育的同事指出该问题为止（或直到​​发生实际的SQLi为止）。

在学习中（很多年前），我们的老师总是告诉我们在创建手动SQL查询时要使用PreparedStatements，因为这是“最佳实践”，但他们没有说为什么。这总比没有好，但还是很可悲。
我不确定那些老师是否还了解自己。

我们学习了如何在jsp上显示内容，但不了解跨站点脚本是什么。因此，很久以前我就自己掌握了所有这些知识，但是我敢肯定，许多开发人员每天仅做8个小时（出于正当理由），只要没有人显示他们出了什么问题，它不会改变。

#13 楼

如果正确使用准备好的语句，则无法进行SQL注入。

“如果原始语句模板不是从外部输入派生的，则不会发生SQL注入。”

https://en.m.wikipedia.org/wiki/Prepared_statement

不幸的是，人们通常根本无法正确使用预处理语句。

如果这样做，SQL注入将成为过去。 />是的，很长一段时间以来，php / MySQL已经有一个准备好的语句实现，如果可以使用内存，则已经有10多年的历史了。

#14 楼

其他答案指出了几乎所有原因。但是还有其他事情，我认为这是所有人中最危险的安全问题。开发人员试图为技术添加越来越多的功能，有时会偏离技术的实际目的。有点像客户端脚本语言最终被用于服务器端编码，还是被允许访问远程资源以及客户端本地存储。大蜜罐。通过研究一些高级SQL注入，我们可以看到它们如何在稳定的SQLi攻击中发挥了作用。 。就像调用run(value, printf)而不是printf(value)一样。

最后一件事，虽然在不同类型的数据库之间进行转换非常容易，但是服务器端代码中所需的更改非常庞大。 >
有人应该在不同类型的数据库之间进行抽象，并使其更容易在不同的数据库之间进行切换。假设有一个php插件，它接受输入QL命令和数据库类型，并且可能是列入白名单的过滤器以清理输入。

#15 楼

我个人认为这是编程中一个更普遍问题的特例，因为IDE和语言过于宽容。我们以灵活性和效率的名义赋予开发人员巨大的力量。结果是“将要发生的一切都会发生”，并且安全漏洞不可避免。

#16 楼

PDO（或其他“安全”方法）不比mysql_（或其他“不安全”方法）安全。它使编写安全代码变得更加容易，但是将未转义的用户提供的字符串连接到查询中，而不必理会参数，则更加简单。