SQL Injection5（cookie注入）
SQL Injection5（cookie注入）
前言
我认为sql注入分为两种类型，一种字符型，一种数字型
这里的cookie注入，包括宽字节注入等等，更像是一种找注入点的方法吧。
cookie注入原理
如果你学过ASP
你应该会知道 Request.QueryString (GET) 或 Request.Form (POST)!
呵，没错，这就是我们用于读取用户发给WEB服务器的指定键中的值!
我们有时为了简化代码，会写成
ID=Request(“ID”)
这样写法是简单了，但问题就来了~~~我们先看WEB服务是怎样读取数据的,他是先取GET中的数据，没有再取POST中的数据,还会去取Cookies中的数据
参考：浅谈cookie注入
从上面的话可以看出，cookie注入是因为一些获取参数的函数会从cookie中寻找数据而引发的。在对方对get和post注入都进行了防御的时候，有可能忽视cookie，所以在get，post直接注入不行的时候可以尝试cookie注入，但其注入的原理与正常注入的原理是一样的，这里只是注入点的发现。
下面的练习是在一个靶场练习，远程连接的攻击机是xp系统，目标机是03系统…实验环境我觉得比较恶劣，最主要很卡…
靶场练习
进入靶场，待攻击页面如下图所示
先来查看有哪些地方存在注入点
首先看到的就是用户登陆窗口，这里是可能存在那种登陆注入的
然后点击新闻内容页面
可以看到搜索框，然后看url可以看id，可以推测文章内容是根据id值去查询数据库得到的，所以这里的两个都是可能存在注入的。
当然再仔细找还能发现更多"嫌疑注入点"。（最近看了下关于sql注入的一些的博文，发现不仅是select可以注入，delete，insert，update都是可能存在注入点的，以前的思维基本都是去找类似搜索框，查询框这样的注入点眼界可能就太窄了…）
这里因为是cookie注入的练习，我就来试一下，先测试id
在url我们直接加上and 1=1 发现返回说有非法字符，说明服务端是有过滤的
get的传参是有过滤的，所以我们来是一下cookie注入。（我记得sqlmap level2好像就会检查cookie了，这里我们继续手工吧）
这里我们把url中的cookie抹掉，在cookie中新建一个id值内容写上27（为什么这么做可以看下cookie注入的原理）然后刷新页面
可以看到页面成功返回了，说明是有希望的，我们来加上 and 1=1
可以看到页面也成功返回了，说明存在注入（这里要url编码），对cookie的传参是接受了并且没做过滤
这时候我们来用order by来判断表查询的字段数
这里发现在order by 12的时候返回错误，说明字段数为11
这时候我是想用联合查询来，用上图的形式去查结果报错…把27换成一个不存在的页面id也不行，这里我很懵逼（这里可以看下面的TIPS第2点），
cookie注入原理
我看了帮助和上面的博客都是直接猜表名…(我用information_schema.tables也报错…不是mysql？)
这里可以看到我把表名换成admin后就没问题了…
然后将2，3替换成username和password试下（为什么替换这两个我也很懵…因为上图中的2，3也不能推测数2，3就分别是username和password吧…可能因为这些值能返回所以有尝试的意义？）
结果还真出来了？？？…
Ok,我们也看到了上面注入的时候很麻烦，每次都要改cookie，所以有一个注入中转的工具来辅助我们
就是上面这个工具，会生成一个asp，在我们机子上搭一个asp服务器，然后把这个asp放进去，接着我们去访问这个asp会看到和我们攻击页面相同的页面，但这里我们就可以直接注入，不需要再改cookie了…
中转注入详解参考：中转注入详解
中转注入原理参考：中转注入原理
但实验环境本地搭的asp服务器貌似有问题访问不了…（这个远程的xp的虚拟机我已经无话可说…真的又卡又难用还不得不用…），最主要这个工具我感觉可能也比较过时了，用的人也不多了，最主要不会也不会影响注入，所以这里就算了？？？反正原理就是做一个中转，当然这里中转之后它建议使用穿山甲（pangolin）这样的注入工具来替代手工，可能也是年代比较久远的工具，菜鸡的我只听过sqlmap…当然其实注入工具还有很多，其实我还听过啊D注入？？？
然后我看到实验机有sqlmap，试了一下
这真的是很老的sqlmap了啊…后面报了什么ascii码的错误，实在不想调了，这个环境实在无力吐槽了，现在已经9102年了啊…靶场环境能不能更新啊…（主要是懒，最主要这个实验环境还不能连外网还卡还xp…）
TIPS
-
order by的理解
order by这里跟数字，是select的字段数不是表的字段数
这里主要是自己以前的理解有问题，一直认为order by是和表的字段数有关，这里成功打脸，可以看到是和select选择的字段数有关
-
对上面实验的疑惑
cookie注入原理
靶场的实验环境和上面博文基本一样
当我用order by查出它有11个字段后，我想直接union select 1,2,3,4,5,6,7,8,9,10,11但会报错
但按照union select 1,2,3,4,5,6,7,8,9,10,11 from admin反而能成功，这里我就不是很理解，为什么不加from admin不行…毕竟这个admin是凭经验猜出来的，但我这样的菜鸟又没有什么经验，可以看下面的图，不加表名和加表名都OK啊，难道是数据库的版本太新？但在靶场环境我用database()，version()等函数都会报错…
这里还希望有大佬能够指点下
总结
本次我觉得主要是对cookie注入原理的理解，通过实验也明白了手工注入时，cookie注入如何去操作。反正感觉越学习越觉得sql注入是十分复杂与庞大的，涉及到数据库的原理，网站的原理等等，所需的知识体系也是很广的，很深的。后面再联系别的漏洞时，也时不时找些sql注入的漏洞来练习着吧…
参考
- cookie注入原理 (这篇博客主要有案例)
- 浅谈cookie注入 （这篇博客我觉得原理讲的是十分清楚的）
- 中转注入详解
- 中转注入原理