1.1 SQL注入漏洞

SQL注入漏洞可以说是已经是一个历史漏洞了,早在15年的阿里峰会上,长亭科技的陈宇森就进行了名为《永别了SQL注入》的演讲,但作为最常见也是大家接触最多的漏洞,我们还是决定写出来,供大家学习。

永别了SQL注入

漏洞描述

SQL注入是网站存在最多也是最简单的漏洞,主要原因是程序员在设计程序时,忽略了对输入字符串中夹带的SQL指令的检查,被数据库误认为是正常的SQL指令而运行,从而使数据库受到攻击,可能导致数据被窃取、更改、删除,以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

我们一般的进行网站访问可以称为正常的web端口访问

SQL注入是如何访问?

(1)SQL注入也是正常的web端口访问

(2)只是传入的参数值并非是程序设计者所希望的,而是传入了嵌套SQL代码的参数值

(3)参数值利用程序处理注入者的逻辑,按注入者的期望执行数据库查询

(4)甚至页面呈现按SQL注入者期望显示

通常情况下,SQL注入的位置包括

  • 表单提交,主要是POST请求,也包括GET请求;

  • URL参数提交,主要为GET请求参数;

  • Cookie参数提交;

  • HTTP请求头部的一些可修改的值,比如Referer、User_Agent等;

  • 一些边缘的输入点,比如.mp3文件的一些文件信息等。

  • ……

漏洞等级

高危

漏洞危害

SQL注入的危害不仅体现在数据库层面上,还有可能危及承载数据库的操作系统;如果SQL注入被用来挂马,还可能用来传播恶意软件等,这些危害包括但不局限于:

(1)数据库信息泄漏:数据库中存放的用户的隐私信息的泄露。作为数据的存储中心,数据库里往往保存着各类的隐私信息,SQL注入攻击能导致这些隐私信息透明于攻击者。

(2)网页篡改:通过操作数据库对特定网页进行篡改。

(3)网站被挂马,传播恶意软件:修改数据库一些字段的值,嵌入网马链接,进行挂马攻击。

(4)数据库被恶意操作:数据库服务器被攻击,数据库的系统管理员帐户被篡改。

(5)服务器被远程控制,被安装后门。经由数据库服务器提供的操作系统支持,让黑客得以修改或控制操作系统。

(6)破坏硬盘数据,瘫痪全系统。

漏洞检测方法

可以使用:

%5c,单引号,双引号,反斜杠,负数, 特殊字符,and,or,xor探测是否存在注 入!

注释符# ­­+交替用,一个不行,就另一个 (一定要在注释符号后加空格,或者URL编码后的空格(%20),否则注释符号 不会产生作用)

1、先判断是数字型还是字符型,如果判断不出来跳到9

2、接着判断有没有括号

3、后面跟上­­+注释符

4、order by判断字段数,如果没法判断,则直接union select 1,2,3一个个测试过去

5、如果返回的页面发生变化,则联合查询

6、如果union select 1,version(),3返回的页面没有发生变化,即联合查询失败,则尝试报错 注入

7、如果报错注入页面也没有把信息显示出来,则延时注入

8、如果延时注入也不行,则导入导出

9、尝试延时注入,如果从1过来的,则三种情况,直接跟payload,参数后面加单引号或者 双引号

漏洞利用方法

注入点分类:

按照注入点类型来分类

(1)数字型注入点

在 Web 端大概是 http://xxx.com/news.php?id=1 这种形式,其注入点 id 类型为数字,所以叫数字型注入点。这一类的 SQL 语句原型大概为 select from 表名 where id=1。组合出来的sql注入语句为:select from news where id=1 and 1=1

(2)字符型注入点

在 Web 端大概是 http://xxx.com/news.php?name=admin 这种形式,其注入点 name 类型为字符类型,所以叫字符型注入点。这一类的 SQL 语句原型大概为 select from 表名 where name='admin'。注意多了引号。组合出来的sql注入语句为:select from news where chr='admin' and 1=1 ' '

闭合单引号chr='admin' union select 1,2,3,4 and '1'='1 ====> chr='admin'(闭合前面单引号) union select 1,2,3,4 and '1'='1'

(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)堆查询注入,可以同时执行多条语句的执行时的注入。

下文将会对这些知识点进行简单介绍,并对并穿插以下waf绕过姿势等

漏洞修复方案

解决SQL注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。 通常使用的方案有:

(1)所有的查询语句都使用数据库提供的参数化查询接口,参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口,使用此接口可以非常有效的防止SQL注入攻击。

(2)对进入数据库的特殊字符('"\<>&*;等)进行转义处理,或编码转换。

(3)确认每种数据的类型,比如数字型的数据就必须是数字,数据库中的存储字段必须对应为int型。

(4)数据长度应该严格规定,能在一定程度上防止比较长的SQL注入语句无法正确执行。

(5)网站每个数据层的编码统一,建议全部使用UTF-8编码,上下层编码不一致有可能导致一些过滤模型被绕过。

(6)严格限制网站用户的数据库的操作权限,给此用户提供仅仅能够满足其工作的权限,从而最大限度的减少注入攻击对数据库的危害。

(7)避免网站显示SQL错误信息,比如类型错误、字段不匹配等,防止攻击者利用这些错误信息进行一些判断。

(8)在网站发布之前建议使用一些专业的SQL注入检测工具进行检测,及时修补这些SQL注入漏洞。

漏洞案例

  • 网络安全实验室注入关

  • sqlilabs

  • btslab

  • webug

  • webgoa

  • Owasp Broken Web Application Project