从零开始SQL注入之三
0x00 废话
我们上次讲解了如何识别数字型的SQL注入以及各种猥琐的方法,什么?没看到有猥琐的方法?自己去上节给出的链接中去看。不过这么多猥琐的方法肯定记不住的,关键还是要领悟内涵嘛!理解了自然能搞出各种猥琐的方法,今天我们就来看看字符型的注入点怎么识别吧。
0x01 识别字符型注入点
还记得我们上次讲的构造True and False吗?这次我们识别的主要方法也是通过这个来判断是否存在注入点的。这次我们采用的例子为Less-1
浏览器中访问:http://127.0.0.1/sqli-labs/Less-1/?id=1
,还是熟悉的配方,还是熟悉的味道!
我们依然使用我们的单引号大法,已经显示错误了。大家肯定都能看到,我就不截图了。现在我们来尝试构造一下永真的条件。我们考虑原来的SQL语句可能是这个样子的:
SELECT * FROM table WHERE id = '$id'
如果我们想用and 1=1
的形式去构造,就需要闭合单引号,那就是要将SQL语句构造成下面这个样子:
SELECT * FROM table WHERE id = '1' and '1'='1'
或者
SELECT * FROM table WHERE id = '1' and ''=''
或者随便谁等于谁,只要构成True条件就可以了。
先来考虑上面的一条,如果想构造成这个样子,就需要我们输入1' and '1'='1
,如果不明白为什么的话,给这个payload的两端加上单引号看一下。下面的那个同理,只不过空肯定等于空嘛。
有童鞋觉得输入这么多好麻烦,有没有简单的方法?
有一个更好理解的方法,考虑下面的代码段:
SELECT * # 我是注释
FROM table # 我也是注释
WHERE id = '$id'
发现了什么?对的,注释,行尾的#
后面的内容全部被当做注释而不被执行。这有什么用呢?如果我们构造了下面这样的SQL语句:
SELECT * FROM table WHRER id = '1' and 1#'
那是不是#
后面的内容全部被当做注释不被执行了?于是多余的单引号我们也不用管它了,确实很方便。我们去试一下!
返回了错误?这个SQL语句应该返回正常内容才对,因为and 1
永真。可为什么报错呢?作者也不知道为什么了。。。。
好吧如果真的是这样作者会被打的。问题出在#
上面,这里我们需要对#
进行URL编码,不然会破坏SQL语句的完整性(当然这仅限于GET注入,POST注入是不用再编码的,你可以先简单的认为GET注入就是出现在GET参数中的注入,POST注入就是出现在POST参数中的注入)。我们继续尝试http://127.0.0.1/sqli-labs/Less-1/?id=1' and 1%23
看看结果。
果然返回了正确的内容。
开个脑洞:http://127.0.0.1/sqli-labs/Less-1/?id=1''(两个单引号)
想想这是为什么?
0x02 单引号大法不是万能的
看这一节的标题就知道我想说什么了,前面也证实过了。很多时候加个单引号确实不会报错的。我们看下面几个SQL语句:
Less-3:
$sql="SELECT * FROM users WHERE id=('$id') LIMIT 0,1";
Less-4:
$id = '"' . $id . '"';
$sql="SELECT * FROM users WHERE id=($id) LIMIT 0,1";
更多的就不再举例了。可以看到这些字符型的除了用单引号包裹外,还用有双引号,括号包裹的,这样一来单引号自然是不管用了。所以在判断字符型的注入点的时候,还是应该多尝试一下其他的符号,更多的例子大家可以看看前面几个Less,基本上常见的也就这么些了。更多的猥琐方法还是看上次的那个链接吧。
0x03 总结
讲完了基本的判断注入点的方法,当然这并不是全部,如果你以为教程到这里就结束的话,你也看不到这一节了。
大家可以自己去前几个Less中尝试识别一下注入点,从下一节开始,我会从Less-1开始逐个分析典型的注入点情况,大家真的吃了红色药丸么。。?
对#进行URL编码,是因为 url 里面的片段 id 不会发送到服务器,比如输入xx.com?a=1'#id实际发送给服务器的只有 xx.com?a=1' 所以报错了
PS: 写的挺好的,希望继续写下去
CRLF-Header:CRLF-Value