随着网络安全技术的发展,SQL注入做为一种很流行的攻击方式被愈来愈多的人所知晓。不少网站也都对SQL注入作了防御,许多网站管理员的作法就是添加一个防注入程序。这时咱们用常规的手段去探测网站的SQL注入漏洞时会被防注入程序阻挡,遇到这种状况咱们该怎么办?难道就没有办法了吗?答案是否认的。javascript
咱们知道,通常的防注入程序都是基于“黑名单”的,根据特征字符串去过滤掉一些危险的字符。通常状况下,黑名单是不安全的,它存在被绕过的风险。好比有的防注入程序只过滤了经过GET、POST方式提交的数据,对经过Cookie方式提交的数据却并无过滤,这时咱们该怎么办?在本文你将会找到答案。html
Cookie注入原理java
Cookie最早是由Netscape(网景)公司提出的,Netscape官方文档中对Cookie的定义是这样的:Cookie是在HTTP协议下,服务器或脚本能够维护客户工做站上信息的一种方式。算法
Cookie的用途很是普遍,在网络中常常能够见到Cookie的身影。它一般被用来辨别用户身份、进行session跟踪,最典型的应用就是保存用户的帐号和密码用来自动登陆网站和电子商务网站中的“购物车”。数据库
Cookie注入简单来讲就是利用Cookie而发起的注入攻击。从本质上来说,Cookie注入与传统的SQL注入并没有不一样,二者都是针对数据库的注入,只是表现形式上略有不一样罢了。浏览器
要想深刻了解Cookie注入的成因,必需要了解ASP脚本中的request对象。它被用来获取客户端提交的数据。先来看下ASP开发文档中对request对象的描述,如图1所示:安全
图1服务器
Request对象的使用方法通常是这样的:request.[集合名称](参数名称),好比获取从表单中提交的数据时能够这样写:request.form("参数名称"),但ASP中规定也能够省略集合名称,直接用这样的方式获取数据:request("参数名称"),当使用这样的方式获取数据时,ASP规定是按QueryString、Form、Cookies、ServerVariables的顺序来获取数据的。这样,当咱们使用request("参数名称")方式获取客户端提交的数据,而且没有对使用request.cookies("参数名称")方式提交的数据进行过滤时,Cookie注入就产生了。cookie
Cookie注入典型步骤网络
上面咱们介绍了Cookie注入的相关知识,下面咱们来看如何肯定一个网站是否存在Cookie注入漏洞。
1.寻找形如“.asp?id=xx”类的带参数的URL。
2.去掉“id=xx”查看页面显示是否正常,若是不正常,说明参数在数据传递中是直接起做用的。
3.清空浏览器地址栏,输入“javascript:alert(document.cookie="id="+escape("xx"));”,按Enter键后弹出一个对话框,内容是“id=xx”,而后用原来的URL刷新页面,若是显示正常,说明应用是用Request("id")这种方式获取数据的。
4.重复上面的步骤,将常规SQL注入中的判断语句带入上面的URL:“javascript:alert(document.cookie="id="+escape("xx and 1=1"));”
“javascript:alert(document.cookie="id="+escape("xx and 1=2"));”。
和常规SQL注入同样,若是分别返回正常和不正常页面,则说明该应用存在注入漏洞,并能够进行cookie注入。
5.使用常规注入语句进行注入便可。
Cookie注入攻击实例
经过上面的介绍,相信读者对Cookie注入的原理和通常的注入流程都有了必定的了解,那么下面咱们就经过一个实际案例来说解一下Cookie注入攻击。
咱们的目标是这个站http://knowsec.3322.org,这是我为了演示Cookie注入攻击而搭建的一个网站。先来看一下网站页面,如图2所示:
图2
咱们随便查看一条新闻,如图3所示:
图3
经过URL咱们了解到这是一个ASP的动态页面,如今咱们用常规的手段去探测一下该网站是否存在SQL注入漏洞。关于SQL注入漏洞的介绍和利用能够参考这篇文章(http://www.rising.com.cn/newsletter/news/2012-05-24/11580.html),这里再也不赘述。咱们先在参数值后面加一单引号,而后提交,发现提示“请不要在参数中包含非法字符尝试注入”,并记录了咱们的IP地址。这时能够肯定该网站添加了防注入程序,对SQL注入中常常用到的字符作了过滤,如图4所示:
图4
接着咱们再用经典的and 1=1和and 1=2试下,发现都被过滤掉,具体以下图5和图6:
图5
图6
看来咱们检测SQL注入漏洞的常规手段不能绕过防注入程序。那咱们还有其余办法吗?答案是有,咱们用下面的方法来试下。
1.咱们把上面URL(http://knowsec.3322.org/onews.asp?Id=33)问号后面的参数去掉,而后访问该页面,提示数据库出错,如图7所示。
图7
2.如今咱们清空浏览器地址栏,输入“javascript:alert(document.cookie="id="+escape("33"));”,按Enter键提交,会弹出一个对话框,如图8所示。
图8
3.如今咱们再来访问这个URL(http://knowsec.3322.org/onews.asp),发现能够正常访问了,如图9所示。
图9
4.根据上面返回的结果来分析,该网站是经过相似owen=request("id")的方式来获取浏览器提交的参数值的。
5.依此类推,咱们能够把and 1=1和and 1=2带入上面的语句中去判断是否有SQL注入漏洞,如图10和图11。
图10
图11
6.如今咱们已经能够肯定该网站存在注入漏洞,而且能够经过Cookie进行注入。
因为手工进行Cookie注入比较繁琐,效率比较低。在理解了Cookie注入的原理之后,咱们能够用工具来提升效率。首先咱们须要用Cookie注入中转工具来生成一个中转页面。先来看下这个小工具的界面和使用方法,如图12。
图12
咱们以URL(http://knowsec.3322.org/onews.asp?id=33)来演示该工具的用法。先切换到COOKIE注入项,在“注入键名”处输入“id=”,在“注入URL地址”和“来源页”处都输入“http://knowsec.3322.org/onews.asp”,“正常的Cookie值”处不用修改,将“POST提交值”jmdcw=后面的值修改成33。以下图13所示:
图13
各项都填好后选择“生成ASP”,以后会在和该工具同一目录下生成一个ASP中转页面。将该页面上传到一个ASP空间,这里我把它放在我一台支持ASP脚本解析的机器上。如今咱们来访问一下http://192.168.30.128/jmCook.asp?jmdcw=33,如图14所示。
图14
OK,能够正常访问。如今就能够按常规方法构造注入语句去注入了。这里我把它直接放到阿D注入工具里去跑,很快就返回告终果,如图15。
图15
如今咱们成功获得了管理员的帐号和密码,密码是加密过的,但很容易破解,加密算法是将密码每一个字符的ASCII码数值加上对应位数的值,再转换为对应字符。帐号root的密码解密后是654321。因为本篇文章讲解的是Cookie注入,因此后面拿WebShell的流程就再也不讲述了,若是有兴趣能够参考其余资料。
Cookie注入防护总结
上面咱们以攻击者的视角经过一个实际案例讲述了Cookie注入攻击,但咱们的目的不是为了去攻击别人,并且为了更好的防护。俗话说“知己知彼,百战不殆”,只有理解了攻击者是如何攻击的,咱们才能更有效地防护。
如今咱们对上面案例中用到的网站程序进行加固,来详细谈下如何化解Cookie注入攻击,先来看下出现漏洞页面的代码,如图16所示。
图16
经过上面的代码咱们能够得知,服务器端在获取到参数id的值后没有作任何处理,直接带入SQL语句中执行查询,这样就产生了一个SQL注入漏洞。
但因为该程序加了防注入程序,对经过GET、POST方式提交的数据进行了过滤,具体来看下代码,如图1七、图18和图19:
图17
图18
图19
经过分析上面的代码,咱们肯定了Cookie注入产生的缘由。网站程序是经过request("id")方式获取客户端提交的数据,而且在防注入程序中没有对经过request.cookies方式提交的数据进行过滤。
如今咱们找到了问题的根源,那么如何来修复这一漏洞呢?有两种解决办法:1、在获取客户端提交的数据时指明数据提交方式,能够采用Request.QueryString("id")方式来获取经过GET方式提交的数据。2、修改防注入程序,增长对Request.Cookies("id")数据提交方式的过滤。
这里咱们采用第一种方法对网站代码进行修改,其实很简单,只须要修改一句代码便可。修改后的代码是这样,具体看下图20:
图20
将修改后的代码上传到网站服务器上,替换掉旧的文件。如今咱们再来看下还可否利用Cookie注入,如图21。
图21
由上图咱们看到如今已经不能经过Cookie进行注入了,漏洞被修复。
来源:瑞星网