目录

前言
概述
Sql 注入产生原因及威胁
如何判断 Sql 注入点
关于sql注入的正确打开方式
未完待续
参考文献

前言

事情的主要的经过是这样子的,在某一个早上我们老大急急忙忙的叫我接收邮件,我就知道应该是线上环境出现了什么问题了的。然后发现是线上的数据库被占用很严重,最后找到了原因主要是由于一条特定的语句,一直在执行,导致数据库被堵塞了。最后经过排查发现,应该是sql注入背的锅,这不就导致我来看这个sql注入来了么,顺便学习一下如何复现和解决问题。

概述

sql注入概念

所谓SQL注入式攻击,就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串,将(恶意)的SQL命令注入到后台数据库执行一些恶意的操作,欺骗服务器执行恶意的SQL命令,实现无帐号登录,甚至篡改数据库。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQL注入式攻击。
它目前黑客对数据库进行攻击的最常用手段之一。

web程序三层架构

三层架构(3-tier architecture) 通常意义上就是将整个业务应用划分为:

  • 界面层(User Interface layer)
  • 业务逻辑层(Business Logic Layer)
  • 数据访问层(Data access layer)。

区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构被应用于众多类型的软件开发。 由数据库驱动的Web应用程序依从三层架构的思想也分为了三层:

  • 表示层。
  • 业务逻辑层(又称领域层)
  • 数据访问层(又称存储层)

拓扑结构如下图所示

在上图中,用户访问网页主要是进行了如下过程:

  • 在 Web 浏览器中输入 www.xxxx.com 连接到实验楼服务器。
  • 业务逻辑层的 Web 服务器从本地存储中加载 index.php 脚本并解析。
  • 脚本连接位于数据访问层的 DBMS(数据库管理系统),并执行 Sql 语句。
  • 数据访问层的数据库管理系统返回 Sql 语句执行结果给 Web 服务器。
  • 业务逻辑层的 Web 服务器将 Web 页面封装成 HTML 格式发送给表示层的 Web 浏览器。
  • 表示层的 Web 浏览器解析 HTML 文件,将内容展示给用户。

在三层架构中,所有通信都必须要经过中间层,简单地说,三层架构是一种线性关系

Sql 注入产生原因及威胁

刚刚讲过当我们访问动态网页时, Web 服务器会向数据访问层发起 Sql 查询请求,如果权限验证通过就会执行 Sql 语句。 这种网站内部直接发送的Sql请求一般不会有危险,但实际情况是很多时候需要结合用户的输入数据动态构造 Sql 语句,如果用户输入的数据被构造成恶意 Sql 代码,Web 应用又未对动态构造的 Sql 语句使用的参数进行审查,则会带来意想不到的危险。

Sql 注入带来的威胁主要有如下几点

  • 猜解后台数据库,这是利用最多的方式,盗取网站的敏感信息。
  • 绕过认证,列如绕过验证登录网站后台。
  • 注入可以借助数据库的存储过程进行提权等操作

如何判断 Sql 注入点

通常情况下,可能存在 Sql 注入漏洞的 Url 是类似这种形式 :http://xxx.xxx.xxx/abcd.php?id=XX 对 Sql 注入的判断,主要有两个方面:

  • 判断该带参数的 Url 是否存在 Sql 注入?
  • 如果存在 Sql 注入,那么属于哪种 Sql 注入?

可能存在 Sql 注入攻击的 ASP/PHP/JSP 动态网页中,一个动态网页中可能只有一个参数,有时可能有多个参数。有时是整型参数,有时是字符串型参数,不能一概而论。总之只要是带有参数的 动态网页且此网页访问了数据库,那么就有可能存在 Sql 注入。如果程序员没有足够的安全意识,没有进行必要的字符过滤,存在SQL注入的可能性就非常大。

判断是否存在 Sql 注入漏洞

最为经典的单引号判断法: 在参数后面加上单引号,比如:

http://xxx/abc.php?id=1'

如果页面返回错误,则存在 Sql 注入。 原因是无论字符型还是整型都会因为单引号个数不匹配而报错。 (如果未报错,不代表不存在 Sql 注入,因为有可能页面对单引号做了过滤,这时可以使用判断语句进行注入,因为此为入门基础课程,就不做深入讲解了)

判断 Sql 注入漏洞的类型

通常 Sql 注入漏洞分为 2 种类型:

  • 数字型
  • 字符型

其实所有的类型都是根据数据库本身表的类型所产生的,在我们创建表的时候会发现其后总有个数据类型的限制,而不同的数据库又有不同的数据类型,但是无论怎么分常用的查询数据类型总是以数字与字符来区分的,所以就会产生注入点为何种类型。 此处输入图片的描述

数字型判断:

当输入的参 x 为整型时,通常 abc.php 中 Sql 语句类型大致如下: select * from <表名> where id = x 这种类型可以使用经典的 and 1=1and 1=2 来判断:

  • Url 地址中输入 http://xxx/abc.php?id= x and 1=1 页面依旧运行正常,继续进行下一步。
  • Url 地址中继续输入 http://xxx/abc.php?id= x and 1=2 页面运行错误,则说明此 Sql 注入为数字型注入。

原因如下: 当输入 and 1=1时,后台执行 Sql 语句:

select * from <表名> where id = x and 1=1 

没有语法错误且逻辑判断为正确,所以返回正常。

当输入 and 1=2时,后台执行 Sql 语句:

select * from <表名> where id = x and 1=<span">2

没有语法错误但是逻辑判断为假,所以返回错误。 我们再使用假设法:如果这是字符型注入的话,我们输入以上语句之后应该出现如下情况:

select * from <表名> where id = 'x and 1=1' 
select * from <表名> where id = 'x and 1=2' 

查询语句将 and 语句全部转换为了字符串,并没有进行 and 的逻辑判断,所以不会出现以上结果,故假设是不成立的。

字符型判断:

当输入的参 x 为字符型时,通常 abc.php 中 SQL 语句类型大致如下: select * from <表名> where id = 'x' 这种类型我们同样可以使用 and '1'='1and '1'='2来判断:

  • Url 地址中输入 http://xxx/abc.php?id= x' and '1'='1 页面运行正常,继续进行下一步。
  • Url 地址中继续输入 http://xxx/abc.php?id= x' and '1'='2 页面运行错误,则说明此 Sql 注入为字符型注入。

原因如下: 当输入 and '1'='1时,后台执行 Sql 语句:

select * from <表名> where id = 'x' and '1'='1'

语法正确,逻辑判断正确,所以返回正确。

当输入 and '1'='2时,后台执行 Sql 语句:

select * from <表名> where id = 'x' and '1'='2'

语法正确,但逻辑判断错误,所以返回正确。同学们同样可以使用假设法来验证。

未完待续

sql注入常用技术还包括:

  • 采用非主流通道技术
  • 避开输入过滤技术
  • 使用特殊的字符
  • 强制产生错误
  • 使用条件语句
  • 利用存储过程
  • 推断技术
  • 宽字节注入
  • urldecode二次注入
  • sql注入防御
  • ……..

关于sql注入的正确打开方式

SQL注入攻击的总体思路

  1. 寻找到SQL注入的位置
  2. 判断服务器类型和后台数据库类型
  3. 针对不通的服务器和数据库特点进行SQL注入攻击

解决方案

sql注入这种问题的话我个人觉得是在前后端都是需要加以判断和处理的。因为前端加了判断之后可以增加注入难度,然后后端增加了判断之后可以预防绕过前端传来的数据。

采用预编译语句集

现在在很多的语言里面对数据的操作都允许使用预编译语句,在这种语句里面内置了对抗sql注入的能力。
好处:

  • 增加了代码的可读性和可维护性
  • 尽可能的提高了性能
  • 提高了安全性

原理:
sql注入主要是在sql的解析过程中对语句进行破坏,但是预编译语句里面已经在之前编译好了,最后只需要把参数传递到里面即可,所以在传递参数之后就没有了sql语句编译的这一个过程,所以就避免了sql注入的类似的问题。

使用正则表达式过滤传入的参数

字符串过滤

jsp中检查是否含有非法字符

参考文献

实验楼sql注入基础实验
这只是一个关于md5解密的链接
防止sql注入的五种方法
php.ini中的关于安全的配置
php中预编译防止sql注入