已经14岁的SQL注入仍然是最危险的漏洞

发布时间：2015-09-18 00:00 来源：未知

自从电脑问世以来，一直有一些人试图破解电脑。1965年，麻省理工的William D. Mathews发现了在IBM7094平台上多路信息计算系统(Multics)兼容分时系统(CTSS)密码文件的一个缺陷；大约在1971年，John T.Draper 发现了一个谷物玩具口哨可以提供免费电话呼叫；当计算机存在的时候，Chaos计算机俱乐部，cDc社区,2600，臭名昭著的Kevin Mitnick，甚至计算机教父艾伦 图灵和他在二战德国英格玛密码克星炸弹，都参与了计算机破解。

从1980到1990，世界开始见证了个人电脑，互联网和万维网的问世。无数家庭中的电话线通过拨号连接发出刺耳的声音。AOL,CompuServe,Juno开始为家庭用户提供信息协议和接入网络的网关。信息时代和信息安全时代到来了

每天有无数的人更新组织网站，其背后的技术也如此。网站有静态的文本和图像过渡到动态迎合定制内容的网站程序。在浏览器中，HTML,CSS和JS变得更 强大的组织内容系统。浏览器自身也在演变，从IE到Netscape,从Firefox到Chrome，等等。PHP和Perl CGI同其他语言一样，成为了网站终端实时生成HTML和其他浏览器渲染的元素的脚本的一种选择。数据库系统变化无常，MySQL成了最流行的系统。实际 上，很多的事物变化无常--.com气泡？但是一件事仍然重要:web程序安全。

安全守护者 - OWASP等

2001年12月成立了开放Web应用安全项目,作为一个 互联网非盈利组织并针对网络安全讨论和进步。  实际上，OWASP尽可能地追踪每种类型的黑客。社交工程，薄弱的认证系统，跨站脚本，SQL注入，一般的软件漏洞等等，OWASP保持追踪并鼓励网络社 区尽可能地保护网络安全。随着互联网的发展，并通过OWASP和它的参与者的努力，有名的黑客也不例外，事情发生了变化。然而，在所有类型的安全攻击中，注入几乎是唯一地保持在前十的攻击方式（通常是特定的数据库SQL注入）

OWASP把注入定义为“不可信的数据被发送到解释器作为命令或查询的一部分”。通常，这种方式允许攻击者未授权地访问web应用中数据库的数据，或者允 许他们插入或者选择一条已经存在的数据。之所以这样是因为web应用使用用户的输入直接插入记录到数据库查询而没有任何类型的处理。

紧接着，可能有人会想，为什么任何人允许未处理的数据流入数据库查询？事实上，假如我们有这个问题的答案，我们可能会得到美国国防部的亿万的美元

插曲:什么是SQL注入？

在进一步讨论之前我们想暂停一下，确保你，我们珍贵的读者能够理解什么是SQL注入和其后的技术层面。为了简洁和集中注意力，我们假设从这里你理解了SQL注入，和它是如何工作以及基本的预防方法。

假如你不能做到，请首先参看文章SQL注入你需要知道的事 并留心后续的文章，而我们则继续深入这个不变的安全问题。理解SQL注入背后的技术有助于突出简单的事物，和这个重复的安全漏洞的荒谬。

回放:SQL注入的历史教训

只要有关系数据库存在，就有SQL注入攻击的媒介。自1999年起，就有了常见漏洞曝光 词典来追踪并警告用户和开发者类似的软件漏洞。2003年之后，SQL注入仍然在CVE列表中排前10.在2003年到2011年，有3260种漏洞。

2012年，Barclaycard的一个代表声称97%的数据泄露都是由SQL注入引起的。2011年年尾和2012年年首，在不到一个月的时间 里，超过百万的网页遭受到LilupophilupopSQL注入攻击.2008年见证了由于SQL注入引起的经济失调。甚至在2010年秋季，联合国官 方网站也遭受SQL注入攻击。

所有这些统计数据(当然排除了CVE统计)都是过去三年以内的。仅仅三年时间。这也难怪在2011年美国国土安全局，Mitre和SANA研究所都把SQL注入作为第一危险的安全漏洞。所以，14年之后，它仍然是首要的貌似难以修复的漏洞。

易下手的漏洞 : 在疏忽中学习或执着

在伦敦大学金匠学院的近期研究中，科研人员得出了一个结论：我们的大脑不易改变所以我们人类往往不会轻易地在我们的错误中进步。开发者看到并全面认识到软 件开发中的一些错误，但是他们内心里却不能战胜并避免犯下过去这些反复的失误，这或许是件简单的事。或者他们见树不见林，即他们完全理解技术细节却没有看 到知识应用的宏图。

至于易下手的漏洞，SQL注入让它们变成了一个礼物，它保证攻击者具有易获得非法访问网站或者其他SQL后台系统。这个结论是基于成功的概率得到的，假如14年的历史数据可信的。从根本上来讲，这主要是由于大多数显而易见的问题：我们仍然使用关系SQL数据库。

假如我们使用NoSQL数据库系统比如MongoDB或者CouchDB,那么这些攻击就不会发生了，或者至少不会像SQL注入那样简单了。但那不是真正 的原因，甚至也不是一个合理可行的解决方案。真正的原因在于软件和web应用开发者们真的像伦敦大学得出的结论一样，一旦人类把事情搞砸了，他们就不能轻 易地学习和适应。

低代价，高回报；利用一个易得手的漏洞

通过比较，一次分不是拒绝服务攻击(DDOS)需要协调和利用数百到数万的被感染的系统来实施这样的攻击。而SQL注入攻击在一台电脑上就可以完成，只需 要你有点耐心，不断尝试，不怕失败，加上一些创造力和运气。完成SQL注入攻击真的不需要掌握太多的技巧。实际上，一个脚本小子在完全不懂任何SQL注入 的情况下都可以完成。通过使用任何一款免费工具，实施攻击就是那么简单。

或许有的SQL注入攻击是由偷工减料的开发或者漏洞引起的，但是实际上，经常有3大经常反复发生的错误导致SQL注入的出现。它们包过以下：

忽视最小特权原则

这个原则相当简单，也频繁地被忽视，它仅声明了一个用户，进程或者其他实体完成其任务的最小需要权限。举个例子，一个日志数据表不需要DELETE和UPDATE权限，而数据库管理员通常授予一个服务所有可能的权限而不是刚好适合所需服务的权限。

敏感数据聚集

没有理由把信用卡数据和文章数据放在同一数据库中。也没有理由明文存储密码或者使用糟糕的哈希技术。假如你把你的数据分段，并分散开，那么你的数据库和其内容就不是有价值的目标。就像，你会把你所有的财产放在家里吗？还是把它们放到保险箱中。

盲目信任未处理的用户输入

这是为什么SQL注入会发生。当用户输入未加处理时，攻击者就有能力完成SQL注入攻击，上面的两点也阐述过。一旦用户通过未加处理的输入获得访问权限，敏感数据的可用性和没有限制的特权给了他们一切想要肆虐。

就是这样的。仅仅上述的三个问题就已经导致了数以百万的网页在短短一个月内遭受攻击，包括联合国官网和一些知名网站。这些问题一直保持在OWASP的前十列表中。这些问题往往很荒唐，它是如此简单的三个问题啊，尽然不断导致SQL注入。我们开发者该如何做呢？

在之后的一系列SQL注入的文章中，我们将继续阐述SQL注入攻击的技术细节以及如何预防。而现在，最强调的重要的一点就是开发者和系统管理员不要掉入前 面提到的三个问题。开发者需要保证，他们为一个web应用实现所需的最小权限，隔离或加密数据来减弱数据库的攻击价值，最重要的是，要经常处理用户输入。 这些在技术上再也简单不过了，假如能像SQL注入一贯地排在前十那样一贯地应用这些原则，就能消除前10名单里的SQL注入攻击。

自动监测Web应用在SQL注入方面的脆弱性

监测站点和Web应用是否在SQL注入方面很脆弱的简单并且快速的方法是使用诸如NetSparker这样的自动web应用安全扫描器对它们进行扫描。

Netsparker是一个很容易误报的自由的web应用安全扫描器，它可用来识别web应用或者web站点中诸如SQL注入和跨站脚本攻击等方面的脆弱性。可以下载Netsparker试用版测试站点的脆弱性，或者通过Netsparker产品描述页面了解更多这方面的信息。

原文链接：https://www.mavitunasecurity.com/blog/sql-injection-vulnerability-history/

译文链接：http://www.oschina.net/translate/sql-injection-vulnerability-history