Birt mysql dataset_动态 SQL 及安全性(Birt vs 润乾)

本文对比分析了Birt和润乾报表在使用动态SQL时的安全性和实现方式。Birt通过数据集脚本拼接SQL,但易出现SQL注入风险,而润乾报表使用动态参数实现,简化了操作且提供了规避风险的配置。文章强调在报表工具选择时,安全性的考虑至关重要。
摘要由CSDN通过智能技术生成

静态 SQL 与动态 SQL

对于题目中提到的动态 SQL,显然应该有一种静态 SQL 与之相对,那么两者应该怎么理解?我们先来个基本的认识。

静态 SQL 之“静态”,意味着在执行之前就已经明确了该 sql 在数据库执行后的业务含义,也就是对于做啥事儿我们是清楚的,只不过需要知道这事儿的具体内容有哪些。比如“select userID,username from users where deptName=’销售部’”,意思就是查销售部的所有用户 ID 及用户名。 再稍微灵活一点,可以写作“select userID,username from users where deptName=?”,此时语句中的“?”传递哪个部门名称,相对应的就查哪个部门的用户信息。但,sql 本身所要做的“查询某部门下的用户信息”这个事情我们是完全明确的,不确定的只是用户有多少,各自的信息是什么。

而动态 SQL 之所以称为“动态”,就是在是否“明确业务含义”这一点上是“不明确”的,也就是说 sql 应该执行出啥结果,我们本身并没有明确的预期,包括查什么、用哪些条件以及怎么组合这些条件等——原则上,这些都可以随意选择组合。

比如:“select userID,userName from users where ${condition}”,此处的 condition 可以随意指定合理的查询条件,当传入“deptName=’xx 部门’”时,执行结果是查询某部门的用户信息;当传入“roleName=’技术主管’”时,则是按照角色筛选复合条件的用户信息。尽管都是返回用户信息,但不同条件下,我们可以认为是两个不同的业务,这里的 sql 我们就称之为是动态的,显然,这样的 sql 执行后得到的结果的业务含义也是完全不确定的。

上面动态 sql 的例子是条件不固定,实际上动态 sql 还允许返回字段不确定,如“select userID,${fields} from users where …”, 需要查询哪些字段,完全由动态指定的”fields”来确定,可以查 deptName,也可以查 userName 和 deptName,非常自由、灵活。

同理,使用的物理表也可能不固定,例如定义为“select … from ${table} where …”时,”table”给定啥值就从哪个表查数据。

结合两者的具体含义,可以分析得到各自的优劣所在:

l静态SQL:功能固定,比较传统,但相对比较安全。

l动态SQL:自由灵活,但同时不得不提到sql植入风险,一旦被攻击者利用可能的sql漏洞,会有相当严重的安全问题,如窃取用户信息、篡改数据等等。

而在常用的报表工具使用场景中,报表开发人员一般都没有DBA的功力,因此难以对sql的安全性问

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值