如果我们使用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产品描述页面了解更多这方面的信息。