Web攻防系列教程之 Cookie注入攻防实战

随着网络安全技术的发展，SQL注入作为一种很流行的攻击方式被越来越多的人所知晓。很多网站也都对SQL注入做了防护，许多网站管理员的做法就是添加一个防注入程序。这时我们用常规的手段去探测网站的SQL注入漏洞时会被防注入程序阻挡，遇到这种情况我们该怎么办？难道就没有办法了吗？答案是否定的。

我们知道，一般的防注入程序都是基于“黑名单”的，根据特征字符串去过滤掉一些危险的字符。一般情况下，黑名单是不安全的，它存在被绕过的风险。比如有的防注入程序只过滤了通过GET、POST方式提交的数据，对通过Cookie方式提交的数据却并没有过滤，这时我们该怎么办？在本文你将会找到答案。

Cookie注入原理

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注入漏洞。

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方式提交的数据进行了过滤，具体来看下代码，如图17、图18和图19：

图17

图18

图19

通过分析上面的代码，我们确定了Cookie注入产生的原因。网站程序是通过request("id")方式获取客户端提交的数据，并且在防注入程序中没有对通过request.cookies方式提交的数据进行过滤。

现在我们找到了问题的根源，那么如何来修复这一漏洞呢？有两种解决办法：一、在获取客户端提交的数据时指明数据提交方式，可以采用Request.QueryString("id")方式来获取通过GET方式提交的数据。二、修改防注入程序，增加对Request.Cookies("id")数据提交方式的过滤。

这里我们采用第一种方法对网站代码进行修改，其实很简单，只需要修改一句代码即可。修改后的代码是这样，具体看下图20：

图20

将修改后的代码上传到网站服务器上，替换掉旧的文件。现在我们再来看下还能否利用Cookie注入，如图21。

图21

由上图我们看到现在已经不能通过Cookie进行注入了，漏洞被修复。