SQL注入（二）

0x01 SQL注入原理

​ web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

SELECT * FROM t1 WHERE id = %s; 

sqlStr := SELECT * FROM t1 WHERE name ='%s' username;

当用户输入1 or 1 = 1

实际上执行的sql 
SELECT * FROM t1 WHERE id = 1 OR 1=1; 

也就是
SELECT * FROM t1;

0x02 SQL注入检测方法

第一步：寻找SQL注入

1、SQL注入可以分为三个步骤

第一步：识别web应用与数据库交互的可能输入（识别潜在注入点）

第二步：SQL注入语句测试

第三步：根据服务器返回判别注入语句是否影响了SQL执行结果以判断是否存在SQL注入。

2、数据提交方式

（1）GET方式注入：get注入方式比较常见，主要是通过url中传输数据到后台，带入到数据库中去执行，可利用联合注入方式直接注入。

（2）POST方式注入：post提交方式主要适用于表单的提交，用于登录框的注入。

方法：利用BurpSuite抓包进行重放修改内容进行，和get差别是需要借助抓包工具进行测试，返回结果主要为代码，也可转化为网页显示。

（3）Request方式注入：超全局变量PHP中的许多预定义变量都是“超全局的”，这意味着它们在一个脚本的全部作用域中都可以用。

这些超全局变量是：

$_REQUEST（获取GET/POST/COOKIE）COOKIE在新版本已经无法获取了
$_POST（获取POST传参）
$_GET（获取GET传参）
$_COOKIE（获取COOKIE传参）
$_SERVER（包含了诸如头部信息(header)、路径(path)、以及脚本位置(script locations)等等信息的数组）

（4）HTTP头注入：通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机响应消息。 这两种类型的消息有一个起始行，一个或者多个头域，一个只是头域结束的空行和可选的消息体组成。 HTTP的头域包括通用头，请求头，响应头和实体头四个部分。

Header头部注入：header注入，该注入是指利用后端验证客户端信息（比如常用的cookie验证）或者通过header中获取客户端的一些信息（比如User-Agent用户代理等其他header字段信息），因为这些信息在某些地方是会和其他信息一起存储到数据库中，然后再在前台显示出来，又因为后台没有经过相对应的信息处理所以构成了sql注入。

3、数据类型：

（1）数字型注入：许多网页链接有类似的结构 http://xxx.com/users.php?id=1 基于此种形式的注入，一般被叫做数字型注入点，缘由是其注入点 id 类型为数字。

例如：查看用户个人信息，查看文章等。

​ 大都会使用这种形式的结构传递id等信息，交给后端，查询出数据库中对应的信息，返回给前台。这一类的 SQL 语句原型大概为：

select * from 表名 where id=1

若存在注入，我们可以构造出类似与如下的sql注入语句进行爆破：

select * from 表名 where id=1 and 1=1

（2）字符型注入：网页链接有类似的结构 http://xxx.com/users.php?name=admin 这种形式，其注入点 name 类型为字符类型，所以叫字符型注入点。

这一类的 SQL 语句原型大概为：

select * from 表名 where name='admin' 

​ 值得注意的是这里相比于数字型注入类型的sql语句原型多了引号，可以是单引号或者是双引号。若存在注入，我们可以构造出类似与如下的sql注入语句进行爆破：

select * from 表名 where name='admin' and 1=1 '

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

select * from 表名 where 字段 like '%关键字%'

若存在注入，我们可以构造出类似与如下的sql注入语句进行爆破：

select * from 表名 where 字段 like '%测试%' and '%1%'='%1%'

(4) xx型注入点

其他型：也就是由于SQL语句拼接方式不同，在SQL中的实际语句为：，其本质为（xx') or 1=1 # ）

常见的闭合符号：'   ''  %   (    {

第二步：确定SQL注入

1、确定数据库类型：

（1）基于应用开发语言判断数据类型

Oracle：JAVA

DB2：JAVA

SQL Server：C#、ASP、.NET

MySQL：php、JAVA

（2）基于报错信息判断

Oracle

SQL Server

MySQL

（3）基于特有函数判断

（4）基于特有数据表判断

2、确认SQL注入方式：

（1）显示注入

union query #联合查询注入，通过union联合查询获取查询结果

error based #报错注入，通过报错信息获取查询结果

（2）盲注

boolean based blind #布尔盲注，通过应用返回不同的值判断条件真假

time based blind #时间盲注，通过不同的时间延迟推断条件真假

优先级：union query error based>boolean based blind>time based blind

0x03 SQL注入危害

1、数据库数据泄露；

2、文件操作，数据读取等；

3、数据泄露可导致后台权限，后台权限导致网站权限，网站权限导致服务器权限。

0x04 修复方案

1、建议修改Web应用服务的软件部分，增加对客户端提交数据（如表单、URL链接）的合法性验证，至少严格过滤SQL语句中的关键字，并且所有验证都应该在服务器端实现，以防客户端（浏览器前端）控制被绕过。

验证部分为get方法中URL后面跟的参数，及post方法中Post的数据参数，需过滤的关键字为：

  [1] ' 单引号
  [2] " 双引号
  [3] % 百分号
  [4] () 括号
  [5] <> 尖括号
  [6] ; 分号
  [7]— 双减号
  [8]+  加号
  [9]SQL关键字，如select，delete，drop等等，注意对于关键字要对大小写都识别，如:select ;SELECT;seLEcT等都应识别。或者使用预处理执行SQL语句，对所有传入SQL语句中的变量，做绑定。这样，用户拼接进来的变量，无论内容是什么，都会被当做替代符号"?"所替代的值，数据库也不会把恶意用户拼接进来的数据，当做部分SQL语句去解析。

2、建议降低Web应用访问使用较低权限的用户访问数据库。不要使用数据库管理员等高权限的用户访问数据库。

3、建议使用较低权限的操作系统帐户启动数据库，不要使用root，或Administrator等帐户启动数据库。