所有的报表工具都会提供参数功能，主要都是用于根据用户输入的查询条件来选取合适的数据。比如希望查询指定时间段的数据，就可以把时间段作为参数传递给报表，报表在从数据库中取数时将这些参数应用到取数 SQL 的 WHERE 条件上，就可以根据不同参数取出不同数据来呈现了。不过，这样做要求事先把查询条件的规格做死，比如按时间段查询，那就要事先把 WHERE 写成 date>=? AND date<=? 的形式。这时候，如果想用地区查询就不行了，还得再造一个形如 area=? 的查询条件或报表。显然，这非常麻烦！
于是，通用查询出现了。报表工具提供一种特殊的字符串型参数，允许将其应用于替换 SQL 的某一部分，比如 WHERE 子句。界面端根据用户输入拼出合法的 SQL 条件串，作为参数传递给报表替换现有 SQL 的 WHERE 子句，这样就可以在同一张报表上实现不同形式的查询条件了。比如 SQL 可以写成
SELECT … FROM T WHERE${w}
其中 ${w} 就是将来会被参数 w 替换的内容。按时间段查询时，可以把 w 拼成 date>… AND data <=…，按地区查询时则拼成 area=…。当然也可以混合多条件查询拼成 data>… AND date<=… AND area=…。无条件时则拼成一个永远为真的条件 1=1。显然，这非常灵活了。
但是，这样做会带来严重的安全隐患。
讨论安全问题时，我们要假定前端没有任何安全性可言，也就是前端很可能被黑客劫持而送入任何可能的参数进来。假如，黑客把上面的 w 拼成
1=0 UNION SELECT … FROM user
送进来。现在整个 SQL 语句就变成
SELECT … FROM T WHERE1=0 UNION SELECT … FROM user
这是一句可执行的合法 SQL，user 表中的信息就被泄露了。
怎么补救呢？我们可以把原始 SQL 的条件上加上括号，写成
SELECT … FROM T WHERE (${w})
的形式。正常的条件串传进来仍然是合法可执行的，而刚才那个攻击串传进来之后，SQL 将变成：
**SELECT … FROM T WHERE (1=0 UNION SELECT … FROM user)
**
这是一句非法的 SQL，会被数据库拒绝，风险似乎就没有了。
且慢，如果黑客把 w 拼成
1=0) UNION SELECT … FROM user WHERE (1=1
整句 SQL 将变成
**SELECT … FROM T WHERE (1=0) UNION SELECT … FROM user WHERE (1=1)
**
还是一句可执行的合法 SQL，仍然会泄露信息。
原则上，我们要假定最坏情况，要保证黑客即使知道数据库结构和报表 SQL 写法时，仍然无法攻击。
我们只能把这个 SQL 写得更复杂一些：
SELECT … FROM T WHERE (${w}) OR${w}
正常的条件串仍然还是合法可执行的，攻击串送进来会变成：
SELECT … FROM T WHERE (1=0) UNION SELECT … FROM user WHERE (1=1) OR1=0) UNION SELECT … FROM user WHERE (1=1
这就非法了，可以挡住这个攻击。
这个写法是不是能挡住所有的 SQL 植入攻击，我没有仔细证明过，试了很多可能的攻击都没问题，有兴趣的读者可以再尝试一下。
无论如何，这个 SQL 已经有点复杂了，而且 SQL 写成这样，执行效率也会受到影响，条件有时候会被执行两次（当 w 为假时，第二遍 w 会没必要地再计算一次）。但为了安全性，却没有什么好办法。
这个例子说明，想挡住 SQL 植入攻击并不是非常轻松的事情。这还只是把替换子句用在 WHERE 的部分，有时为了灵活选出字段，还可能把替换子句用到 SELECT 甚至 FROM 部分，情况就更为复杂。我想，对于相当多对安全意识还不够强的报表开发人员来讲，想到这些并且避免都不是一件容易的事，但又是一件非常重要的事。
从这个意义上讲，使用传统的参数方案（本文开头的说法）在有些时候还是相当必要的，这种方案下只能执行固定的 SQL，不可能被植入，虽然条件方面不够灵活，但安全性可靠得多。有个别报表工具为了简单灵活而只提供了子句替换的方案，在选型考察时要特别加以注意，毕竟报表开发人员很可能会忽略这个问题，而这种安全漏洞又不是很容易被测试出来的，但一旦发生的后果都会很严重。
还有个办法是由报表工具提供敏感词检查，当传进来的替换子句包含某些特定词的时候将被拒绝掉，比如很少有人会用 select,from 这些 SQL 关键字作为字段名，那么，我们判断一下如果替换子句中包含有 select,from 这些词时，就认为受到攻击并拒绝执行。这样做会牺牲一点灵活性，有时传进来的子句真的会含有这些关键字，比如拼入 SELECT 或 FROM 部分的子句，不过这种情况相对少见，损失不大，但获得了较好的安全性。
