报表的 SQL 植入风险及规避方法
互联网时代带来方便的同时也带来了安全隐患，各种安全问题可说是防不胜防，特别是大家日益关心的个人信息等方面，貌似很难有什么安全和隐私可言。
而在报表作为常用的信息载体，更是直接面临各种安全挑战，例如：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 表的风险。
因此建议，“永远”不要使用管理员权限连接数据库，而应该为每个应用使用单独的、权限有限的数据库连接。
报表和 SQL 植入有啥关系？
由于大多数报表工具都会提供参数功能，根据用户输入的查询条件来筛选合适的数据，因此就给 SQL 植入提供了可乘之机。
例如，如果希望查询指定时间段的数据，可以把时间段作为参数传递给报表，报表在从数据库中取数时将这些参数拼接到取数 SQL 的 WHERE 条件上，就可以根据不同参数取出不同数据来进行呈现了。这种方式要求事先把查询条件做死，也就是固定了对应的条件字段。 比如下面这种传统做法：
sql：select * from t where date>=? and date<=?
这个 SQL 定义的数据集专用于按时间段查询，如果想用地区查询就不行了，需要再做一个 area=? 的查询条件或报表。显然非常麻烦……
如果报表工具只支持这种普通用法，自然不够灵活，可能就会限制报表工具的功能，于是“通用查询”这个大招儿就出现了。
报表工具提供了一种特殊的字符串型参数，允许应用其直接替换 SQL 的某一部分，比如 WHERE 子句。界面端则根据用户的输入拼出合法的 SQL 条件串，作为参数传递给报表替换现有 SQL 的 WHERE 子句，这样就可以在同一张报表上实现不同形式的查询条件了。比如数据集的 SQL 可以写成：
SELECT … FROM T WHERE ${mac}
其中 ${mac} 就是将来会被参数 mac 替换的内容。按时间段查询时，可以把 mac 拼成 date>… AND data <=…，按地区查询时则拼成 area=…；当然还可以混合多条件查询拼成 data>… AND date<=… AND area=…；而无条件时则拼成一个永远为真的条件 1=1。
是的，这非常灵活了。
But，带来了灵活性的同时也带来了 sql 植入的风险……可能的植入风险及基于 sql 的规避方法请研读此文章： 报表工具的 SQL 植入风险 ](https://c.raqsoft.com.cn/article/1535513599294)。（报表与 sql 植入的关系，也引自此文。）
报表工具规避 SQL 植入
上面的内容以及所链接的文章介绍了通过 sql 本身的一些限制来防止 sql 注入，那么报表工具能不能也提供一些方法呢？比如著名的润乾报表。
答案肯定是有的。
目前，报表工具一般都会提供敏感词检查，当传进来的替换子句中包含某些特定词时将被拒绝，比如很少有人会用 select,from union 这些 SQL 关键字作为字段名，那么，我们可以首先判断一下替换子句中是否包含有 select,from 这些词，如果有就可以认为受到攻击并拒绝执行。这样做肯定会牺牲一点灵活性，例如有时传进来的子句万一真的会含有这些关键字，不过这种情况相对少见，在获得了较好的安全性的同时，损失的灵活性可以接受。
下面我们就看一下，润乾报表里具体怎么用这种方法？
两种方式：
1、raqsoftConfig.xml 配置需要检查的敏感词列表
该方法是由产品提供的方法，配置好敏感词列表后，报表计算时首先会对每个参数值逐一检查，一旦发现检查不通过的情况，报表不再继续执行，并返回错误信息。
配置如
属性名：disallowedParamWordList，value 为禁用敏感词列表，多个之间用逗号分隔，英文字母不区分大小写。
这个方式用起来很简单，直接改配置，实施或维护人员就能简单操作。
如访问 Url：http://localhost:6868/demo/reportJsp/showReport.jsp?rpx=a.rpx&ar g2= 华北 union select * from users，其中红色部分为通过参数 arg2 植入的 sql
此时会报错，报表数据集（sql）不会再执行。
2、自定义参数检查类
对应方法 1，更为灵活。
（1）对所有参数值检查，代替方法 1
（2）针对某些指定的参数进行检查
（3）错误信息可自定义
public class … implements IParamChecker {
// 校验不通过返回 false，提供 paramName 以便用户只检查某种形式的参数
public boolean check(String s, String s1) {
//s 为报表–参数内，定义的参数名；s1 为报表接收到的对应 s 的参数值
return false;
}
// 检验不通过时，可获取详细信息
public String getCause() {
return “错误信息”;
}
}
接口为 IParamChecker，两个方法：check()为检查实现，getCause() 负责返回错误信息。
下面是介绍使用方法的简单代码示例：
（1）实现自定义类
A、对所有参数值检查
public class ResistSQLInject implements IParamChecker {
private String cause = "";
private List wordList = new ArrayList();
public boolean check(String paramName, String inputValue) {
if(inputValue == null || inputValue.length() == 0){// 如果参数值为空，则无需检查
return true;
}
if(wordList == null){ // 如果检测关键字列表是空，则不作检查
return true;
}
for(int i = 0; i < wordList.size(); i++){
inputValue = inputValue.toLowerCase();// 这里做，是为了不区分大小写
if(inputValue.indexOf(wordList.get(i).toLowerCase())>= 0){
return false;
}
}
return true;
}
public String getCause() {
String tmp = this.cause;
this.cause = "";
return tmp;
}
}
B、针对某些参数检查
private String cause = "";
private List wordList = new ArrayList();
/*
* @paramName 验证的参数名
* @inputValue 验证的参数值
*/
public boolean check(String paramName, String inputValue) {
//wordList.add(“select”);
if(wordList == null){ // 如果检测关键字列表是空，则不作检查
return true;
}
if(paramName==“userID”){
if(inputValue == null || inputValue.length() == 0){// 如果参数值为空，则无需检查
return true;
}
for(int i = 0; i < wordList.size(); i++){
inputValue = inputValue.toLowerCase();// 这里做，是为了不区分大小写
if(inputValue.indexOf(wordList.get(i).toLowerCase())>= 0){
StringBuffer sb = new StringBuffer();
sb.append(“校验未通过，”).append(paramName).append(“参数中含有以下词汇：”).append(wordList.get(i))
.append(“\n 位置：”).append(inputValue.indexOf(wordList.get(i).toLowerCase()));
this.cause = sb.toString();
return false;
}
}
}
return true;
}
C、自定义错误信息
public boolean check(String paramName, String inputValue) {
//wordList.add(“select”);
if(wordList == null){ // 如果检测关键字列表是空，则不作检查
return true;
}
if(inputValue == null || inputValue.length() == 0){// 如果参数值为空，则无需检查
return true;
}
for(int i = 0; i < wordList.size(); i++){
inputValue = inputValue.toLowerCase();// 这里做，是为了不区分大小写
if(inputValue.indexOf(wordList.get(i).toLowerCase())>= 0){
StringBuffer sb = new StringBuffer();
sb.append(“参数：”).append(paramName).append(“检查未通过，”).append(“含有以下敏感词汇：”).append(wordList.get(i))
.append(“。\n 谨记：\n”).append(“道路千万条 \n 规范第一条 \n 数据不规范 \n 亲人两行泪”);
this.cause = sb.toString();
return false;
}
}
return true;
}
（2）配置自定义类
xml（raqsoftConfig.xml）：
paramCheckClass 设置参数值校验的类路径
自定义错误信息的效果：
访问 URL：http://localhost:6868/demo/reportJsp/showReport.jsp?rpx=a.rpx&arg2= 华北 union select * from users
总结，作为应用开发，代码中应尽量避免拼 sql 的方式，相应地可以考虑 prepardStatement，从而避免 sql 植入的风险。而作为报表工具，如果提供了 sql 子句替换的方案，一定要考虑 sql 植入的风险，毕竟报表开发人员不是 dba，这种安全漏洞一旦发生，后果非常严重。
更多集成部署安全相关问题请查看：集成部署相关问题分类导航
* 报表安全的自我检查
* Mac 环境中部署报表
* 润乾报表权限管理机制
* 如何把润乾报表嵌入 web 应用中
* 润乾报表数据权限控制方案
* 润乾报表集群缓存同步功能介绍
对润乾产品感兴趣的小伙伴，一定要知道软件还能这样卖哟性价比还不过瘾？ 欢迎加入好多乾计划。
这里可以低价购买软件产品，让已经亲民的价格更加便宜！
这里可以销售产品获取佣金，赚满钱包成为土豪不再是梦！
这里还可以推荐分享抢红包，每次都是好几块钱的巨款哟！
来吧，现在就加入，拿起手机扫码，开始乾包之旅
嗯，还不太了解好多乾？
