概念
SQL注入是一种欺骗数据库服务器的攻击手段,通过修改或拼接web界面中表单域、原URL或数据包输入的参数为SQL语句,输入到web服务器中进而使数据库服务器执行数据库命令。
简单的说,就是在输入字符串中嵌入SQL命令,在设计程序中忽略了对特殊字符串的检查,这些嵌入的指令便会被误认为是正常的SQL命令从而在数据库中执行,从而攻击成功。
假如一个网站的页面显示URL为example.com?test=111,此时URL实际向服务器传递了值为111的变量test,这表明当前页面是对数据库进行动态查询的结果,此时在URL中插入恶意SQL语句并执行。
例如一个网站登录验证的 SQL 查询代码为:
strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ password +"');"
如果填入以下内容:
userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";
那么 SQL 查询字符串为:
strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
此时无需验证通过就能执行以下查询:
strSQL = "SELECT * FROM users;"
分类
目前SQL注入大致分为普通注入和盲注:
普通注入
根据后台数据库提示有价值的错误信息进行注入。
盲注
有经验的管理员在给出代码有漏洞的页面时,没有提供详细的错误信息。
攻击者需要运用脚本通过仅有的判断信息(比如时间差)对表中的每一个字段进行探测,从而实现注入的技术(盲注的难度较大,但注入测试中经常会遇到)。
危害
只要是使用数据库开发的应用系统就可能存在SQL注入攻击。
自1999年起,SQL注入就成了常见安全漏洞之一,SQL注入漏洞至今仍然在CVE列表中排前十。
防范SQL注入的方法
错误消息处理
要防御SQL注入,就要避免在网页中出现一些详细的错误信息。
攻击者可以利用这些信息来插入SQL语句,因此使用一种标准的输入确认机制来验证所有的输入数据的类型、长度、规则、语句等。
输入验证
检查用户输入的合法性,尽量限制用户输入特殊的符号,确保输入的内容只包含合法的数据。
在客户端和服务器端都要执行用户输入检查。之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性。
加密处理
没有加密的数据可以被直接利用,但是加密了就不一定会解密成功,因此尽量不要使用一些常见的加密算法,就算用也要使用32位以上的加密算法,将用户登录名称、密码等数据加密保存。
加密用户输入的数据,然后再将它与数据库中保存的数据比较,这相当于对用户输入的数据进行了“消毒”处理,用户输入的数据不再对数据库有任何特殊的意义,从而也就使攻击者无法利用用户输入来注入SQL命令。
存储过程来执行所有的查询
SQL参数的传递方式将防止利用单引号和连字符实施注入。
此外,它还使得数据库权限只允许特定的存储过程执行,所有的用户输入必须遵从被调用的存储过程,这样就很难再发生SQL注入了。