网络安全基础——SQL注入漏洞（一）

SQL注入的原理
前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。
注入的关键在于 构造闭合
本文章将以pikachu靶场作为演示实验场景

数字&字符型注入

数字型、字符型注入的判断
判断数字型：在注入点输入

1 and 1=1 ，1 and 1=2，

第一个返回正常第二次返回错误，则为数字型

判断字符型：基本原理同上，但是需加入单引号做闭合

1’ and ‘1’=‘1，1’ and ‘1’='2

在pikachu靶场中做实际演示

数字型注入（POST）
在此场景，可以发现无输入框，通过传输下拉列表的数据

看到查询userid为1的时候，会传回来名字kobe和他的email
抓包，发送到repeater

id在数据包中以明文传输，给了我们可乘之机
修改id数据为

1 or 1=1#

点击发送，可以看到数据库内的所有数据被爆了出来。

字符型注入（GET）
在这个场景中，数据是以GET方式传输，可以看到url中包含了我们所查询的信息allen

对这个name做点手脚，payload和数字型的原理相同

a’ or ‘1’='1

可以看到数据被爆了出来。
在字符型中要注意使用单引号闭合。

代码原理
先看看这个数字型的

问题出在了sql语句这里，传入的数据未做任何处理就拼接到了sql语句中,就成了下面这样

select username,email from member where id=1 or 1=1

当sql语句执行where判断条件时，由于1=1时恒为真的，所以不管前面id=几这条sql语句都会被当成正确的语句被执行，导致了sql注入。

再看这个字符型的，和数字型的原理一模一样，输入的数据拼接到sql语句中后

select id,email from member where username=‘a’ or ‘1’=‘1’

此时就显现除了单引号闭合的作用。

---

联合查询注入

使用union进行联合查询注入
使用union的前提是需要知道当前sql语句一共有多少列名，常用方法是order by判断列数。原理是order by是根据某一列进行排序的，如果输入的值大于所查询的属性个数就会报错。
在字符型注入场景内尝试这一方法。
例：在注入点输入

// # 的作用是为了把后面的单引号注释掉
a’ order by 5#

如页面返回报错，则说明所查询的属性个数是少于5的，这时可利用“二分法查找”，如输入order by 3或者2，查看页面是否报错，如若报错，则再向下分。
反之，页面如果返回正确信息，则向上翻倍，输入order by 10，根据页面返回情况在在进行翻倍或平分，直至找出sql语句所查询的属性个数。


输入5时报错，2时返回正常，这里pikachu最终的测试结果是2，构造联合查询语句

a’ union select database(),user()#

可以看到database()和user()两个数据库函数发挥了作用，这里可以使用更多的方法，比如利用information_schema

a’ union select 1,(select group_concat(table_name) from information_schema.tables where table_schema=‘pikachu’)#

这种利用方法，我以后的文章内会详细解释。

---

宽字节注入

当GBC开启或者遇到addslashes()函数时，单引号双引号等敏感字符会被反斜杠 “\” 转义
首先先了解一下GBK编码，GBK采用双字节表示，两个字节为一个字符。
当在单引号前加入一个字符，如%df，在单引号转义时%df’会变成%df%5c%27，由于GBK时双字节，所以%df%5c会被识别成一个汉字，这样单引号就逃逸了出来。

感谢大家阅读，如有不足，恳请指正！