MySQL宽字节注入漏洞分析_CTF/CTF练习平台 --SQL注入测试【sql宽字节注入与#，#】...

原题内容：

http://103.238.227.13:10083/

这题其实就是考验sql注入基本功,写个wp记录下自己的几个失误点，与大家共同学习

首先，打开页面可见

题目提示的很明显了，这是一个注入题，我们肯定得找到注入点，一般的思路都是'闭合导致注入，关键是找到什么数据被传入了数据库，才能确定注入点

按照常规思路，习惯性加上一个index.php，没问题，可以，再试试get进去个变量？id=1(至于道理是什么，我只能说做多了就知道这么尝试，不必细究怎么想到，网址看到了就知道这么试了)

加上?id =1,页面不变，为了进一步确定id与这个页面有关，将id 的get进去的数值修改成0,3,2,4等等，我们会发现，除了0,1，其他的数值都会使页面改变，按照常理，八成就是id这个注入点了

好的首先尝试sqlmap(一般ctf能直接sqlmap跑的都是不存在的，不过还是试试，假如可以就舒服了)，不出意料，失败

再，开始尝试手动注入：

http://103.238.227.13:10083/index.php?id=1%27%20and%20sleep(5)#

很遗憾，毫无反应

谈到注入，最简单的当然就是毫无防御的注入了，其次自然是宽字节注入，至于何为宽字节注入，详情参考MySQL宽字节注入漏洞分析

尝试宽字节:

http://103.238.227.13:10083/index.php?id=1%df%27%20and%20sleep(5)#

还是很舒服的，虽然是报错，但是有报错说明已经成功就如数据库执行了，报错如下：

这个报错真的研究了很久，百度也没看到啥解释(吐槽下百度知道的一个回答，不管怎么说，肯定你这语句有问题，，服气，这还是最佳答案)

后来回顾自己以前做的一些注入题，对比了一下，看到了问题

urldecode的问题，#，，，，没错就是这个，自己写成%23就没事了，'之类的的自动转换了，#没有，所以解密的时候有问题，数据库报错

至于%23，这种加密结果怎么来的，很简单，对应的ascii表，16进制的数字加上%就是urlencode的结果

http://103.238.227.13:10083/index.php?id=1%df%27%20and%20sleep(5)%23

果然没问题，五秒延迟显示

接下来就开始select

http://103.238.227.13:10083/index.php?id=1%df%27%20union%20select%20string%20from%20key%20where%20id%20=1%23

又有报错，语法错误，执行不了

这里补充第二个点，表要用``框起来(注意不是单引号，是键盘1左边键上面的那个符号，反单引号)

这里看了一下别人的wp也有人说是，key字段名与表名重复，所以表带上了sql5.key，而``是明确告诉是key表，也区分开了表与字段

http://103.238.227.13:10083/index.php?id=1%df%27%20union%20select%20string%20from%20`key`%20where%20id%20=1%23

第三处重点

这个其实还是很好理解的啊，看一下输出格式就知道了，格式与输出的不匹配，所以加上一列

http://103.238.227.13:10083/index.php?id=1%df%27%20union%20select%202,string%20from%20`key`%20where%20id%20=1%23

没问题，拿到flag了，这里的数字2是我随意加的，反正加一列满足下格式就行了