报表工具的 SQL 植入sql注入风险及规避方法

原文链接：http://c.raqsoft.com.cn/article/1561683907950?r=CGQ

 

 

互联网时代带来方便的同时也带来了安全隐患，各种安全问题可说是防不胜防，特别是大家日益关心的个人信息等方面，貌似很难有什么安全和隐私可言。

而在报表作为常用的信息载体，更是直接面临各种安全挑战，例如：SQL 植入。

什么是 SQL 植入？！

报表为啥会有 SQL 植入风险？！

能不能通过报表工具提供的功能避免 SQL 植入？！

SQL 植入的概念

首先，认识一下什么是 sql 植入？

Sql 植入也常被叫做 SQL 注入，具体的做法是通过把 SQL 命令插入到 Web 表单项或页面请求（Url）的查询字符串中提交，最终达到欺骗服务器执行恶意操作的目的。

常见案例包括通过植入 SQL 骗过登录验证。而之前很多影视网站泄露 VIP 会员密码的事件，很多就是通过 sql 植入到 WEB 表单暴出的，并且这类表单特别容易受到攻击。通过 SQL 植入，不仅可以非法获取账号信息，严重的还能够篡改、删除重要数据信息。

为什么存在 SQL 植入呢？

知道了 sql 植入的概念，我们也应该了解为什么会出现 SQL 植入，问题出现在哪个环节？

上图是一个最简单的三层架构的应用结构，包括业务展现层、 数据处理层、数据源。也可以理解成我们常说的前端、后台、后台数据源。

其中，数据源里有个叫数据库的东西，这是最常见的数据管理和存储方式，而关系型数据库那就更常见了，比如 oracle、db2、mysql 等。

开发的应用（数据处理层，也就是后台）为了和操作数据库（增删改查），必须和数据库之间有交流的接口，例如 jdbc 或 odbc，这对于技术人员或是 IT 销售人员也是耳熟能详的。

对于数据库的操作，尤其关系型的，普遍使用的就是 sql 语言。SQL 是一种高级的非过程化语言，只描述做什么而不需要告诉数据库怎么做。 SQL 脚本通过 api 以字符串方式传入数据库，数据库收到 sql 后只管执行然后将结果返回。对于数据库本身来说，它是不知道传来的 sql 是合法还是不合法的，而正是这种完全的信任，导致出现了 sql 植入的风险。

归根结底，SQL 植入利用了应用程序的漏洞，如果编写数据处理的代码时没有充分考虑 sql 植入风险，攻击者将很容易将 sql 命令植入后台数据库引擎执行。而这些不是按照设计者或开发者的意图去执行的 sql 命令都会被视为恶意代码。

如何攻击？

了解了 sql 植入攻击的基本原理，我们就来看看具体怎么攻击。多种多样的攻击方式中比较常见的包括：

1、特殊的输入参数

2、未处理特殊字符“–”、“#”

3、利用不合理的数据库配置

案例 1、特殊的输入参数

常见的如 union 或 or，这是 sql 内的关键字，一个用作多 sql 的归并，另一个则常用在 where 条件中。

以 Union 为例，如果攻击者在一条正常可执行的 sql 后，通过猜表名的方式拼入“union select … from user”，那么 user 表信息就完全暴露了。

Or 呢？可以使得 where 条件变的恒真，以“骗过登录验证”为例：

在程序中我们一般拼 sql 为：strSQL = “SELECT * FROM users WHERE userID = ’” + userID + “’ and pw = ’”+ passWord +“’;”

如果此时 userID 传入 1 or 1=1 ，passWord 传入 ‘1’ or 1=1， 完整的 strSQL 就变成了：“SELECT * FROM users WHERE userID=1 OR 1=1 and pw =’ 1’ OR 1=1;”

很显然，where 条件变为恒真，也就成功骗过了验证，登录进了系统。

案例 2、未处理特殊字符

以常用的注释符“–” 为例：一般的数据库均采用其作为注释符。另外，mysql 还支持“#”注释。

接下来看注释符怎么骗过登录验证。

程序 sql 依然定义为：strSQL = “select * from users where userID=”+userID+“and password=”+psw

此时 userID 传入：’’ or 1=1 –

完整 sql 则拼为：select * from users where userID=’’ or 1=1 – and password = …

“–”之后的脚本作为注释不再执行，实际条件也成了恒真，成功骗过验证，侵入系统。

对于 mysql 数据库，把“–”改为“#”同样可以实现注入。

案例 3、利用不合理的数据库配置

常见的是权限配置不合理、过高，就会有 update 和 delele 甚至 drop 表的风险。

因此建议，“永远”不要使用管理员权限连接数据库，而应该为每个应用使用单独的、权限有限的数据库连接。