sql注入解释

SQL注入攻击是黑客对数据库进行攻击的常用手段之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。

SQL注入是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以目前市面的防火墙都不会对SQL注入发出警报，如果管理员没查看IIS日志的习惯，可能被入侵很长时间都不会发觉。

Michael Sutton 最近发表了一篇非常发人深省的帖子，讲述在公共网上这问题是多么地普遍。他用Google的Search API建了一个C#的客户端程序，寻找那些易受SQL 注入攻击的网站。其步骤很简单：
1、寻找那些带查询字符串的网站(例如，查询那些在URL里带有 "id=" 的URL)
2、给这些确定为动态的网站发送一个请求，改变其中的id=语句，带一个额外的单引号，来试图取消其中的SQL语句(例如，如 id=6' )
3、分析返回的回复，在其中查找象“SQL” 和“query”这样的词，这往往表示应用返回了详细的错误消息(这本身也是很糟糕的)
4、检查错误消息是否表示发送到SQL服务器的参数没有被正确加码(encoded)，如果如此，那么表示可对该网站进行SQL注入攻击。

有几种情形使得SQL注入攻击成为可能。最常见的原因是，你动态地构造了SQL语句，却没有使用正确地加了码(encoded)的参数。譬如，考虑这个SQL查询的编码，其目的是根据由查询字符串提供的社会保险号码(social security number(SSN))来查询作者(Authors)：sql = "SELECT au_lname, au_fname FROM authors WHERE au_id = '" + SSN + "'";

如果你有象上面这个片断一样的SQL编码，那么你的整个数据库和应用可以远程地被黑掉。怎么会呢？在普通情形下，用户会使用一个社会保险号码来访问这个网站，编码是象这样执行的：
' URL to the page containing the above code --> http://mysite.com/listauthordetails.aspx?SSN=172-32-9999
' SQL Query executed against the database --> SELECT au_lname, au_fname FROM authors WHERE au_id = '172-32-9999'

这是开发人员预期的做法，通过社会保险号码来查询数据库中作者的信息。但因为参数值没有被正确地加码，黑客可以很容易地修改查询字符串的值，在要执行的值后面嵌入附加的SQL语句 。譬如，
' URL to the page containing the above code --> http://mysite.com/listauthordetails.aspx?SSN=172-32-9999';DROP DATABASE pubs --
' SQL Query executed against the database --> SELECT au_lname, au_fname FROM authors WHERE au_id = '';DROP DATABASE pubs --

注意到没有，可以在SSN查询字符串值的后面添加“ ';DROP DATABASE pubs -- ”，通过 “;”字符来终止当前的SQL语句，然后添加了自己的恶意的SQL语句，然后把语句的其他部分用“--”字符串注释掉。因为是手工在编码里构造SQL语句，最后把这个字符串传给了数据库，数据库会先对authors表进行查询，然后把我们的pubs数据库删除。“砰(bang)”的一声，数据库就没了！

万一你认为匿名黑客删除你的数据库的结果很坏，但不幸的是，实际上，这在SQL注入攻击所涉及的情形中算是比较好的。一个黑客可以不单纯摧毁数据，而是使用上面这个编码的弱点，执行一个JOIN语句，来获取你数据库里的所有数据，显示在页面上，允许他们获取用户名，密码，信用卡号码等等。他们也可以添加 UPDATE/INSERT 语句改变产品的价格，添加新的管理员账号，真的搞砸你(screw up your life)呢。想象一下，到月底检查库存时，发现你库房里的实际产品数与你的账目系统(accounting system)汇报的数目有所不同。