SQL注入已是一个老生常谈的话题，但时至今日仍是我们作为开发人员和数据库专业人员所面临的最大安全风险之一。
每年都有数以百万计的个人用户信息被泄露，这大部分都是由于代码编写过程中SQL查询语句不严谨造成的。其实只要正确的编写，SQL注入是完全可以预防的。
本文我将着重说明人们对SQL注入常见的四个误解。安全无小事，任何人都不应对此抱有任何的幻想！
1.”我的数据库信息并未公开，因此这是安全的“
可能你对数据库信息的保密工作做的很到位，但这样真的就安全了吗？攻击者其实只需具备对常见数据库库名表名的了解，就完全有可能猜出它们。例如在你的数据库中可能创建了以下的表：
Users
Inventory
Products
Sales
等…
这都是一些使用率非常高的表名，特别是一些数据库开发人员为了节约时间，使用默认表名的情况。这些都是非常危险的操作，应从初始的开发上对这些细节重视起来。
2.”创建混淆性的表名列名，命名约定只有自己能理解“
这样做看似攻击者就无法轻易的猜解出名称了，但你千万不要忽视了像sys.objects和sys.columns这样的系统表的存在！
SELECT
t.name, c.name
FROM
sys.objects t
INNER JOIN sys.columns c on t.object_id = c.object_id
on t.object_id = c.object_id
攻击者可以轻松地编写以上查询，从而获知你的“安全”命名约定。
如果你有不常用的表名，那很好，但千万不要将它作为你唯一的防御手段。
3.“注入是开发者/dba/其他人该解决的问题”
确实SQL注入是开发人员/dba/其他人该解决的问题。但这绝对不是单方面人员的问题，安全是需要多层面的配合的，无论是开发人员/dba/其他人都需要解决问题。
防止sql注入很困难。
开发者应该验证，过滤，参数化……DBA应该参数化，过滤，限制访问等。
应用程序和数据库中的多层安全性是有效防止SQL注入攻击的唯一方法。
4.“网络上的目标众多，被攻击的对象绝对不会是我”
或许你觉得你不会那么倒霉，或者你的业务数据不值得攻击者窃取。但你别忘了大多数的SQL注入攻击，都可以使用像sqlmap这样的完全自动化的工具。他们或许对你的业务并不关心，但这并不妨碍他们通过自动化的方式窃取你的用户数据。
记住！无论你的业务规模大小，都无法避免来自自动化SQL注入工具的威胁。
