在 SAP HANA 项目里写存储过程时,很容易遇到一种看起来相当普通的需求。业务希望把表名、列名、过滤条件,甚至准备创建的对象名称作为参数传进过程里,由程序在运行期间决定最终执行哪一条 SQL。
如果只是普通查询,这件事通常不复杂。一个订单号、客户编号、日期范围或者状态值,都可以作为参数交给 SQLScript,再让数据库完成过滤。
麻烦往往从表名开始。
假设我们的程序收到一个表名,业务希望运行类似SELECT * FROM 某张表的逻辑。这里的表名不是普通数据,而是 SQL 语法结构的一部分。数据库在解析 SQL 时,需要知道它究竟要访问哪个对象,因此很多地方无法像普通WHERE条件那样直接绑定一个变量。
再往前走一步,如果业务要求根据参数创建表,甚至动态决定 Schema、表名、列名,问题会更加明显。
这正是 SAP 在SQLScript Security Considerations中专门讨论Dynamic SQL与Escape Code的原因。SAP HANA Cloud 当前的 SQLScript 安全文档仍然明确提醒,SQLScript 可以读写数据库内容,而某些命令与参数组合会制造数据泄露、数据篡改以及 SQL 注入风险。官方建议尽量使用静态 SQL、检查输入参数、限制过程能力,并谨慎处理动态 SQL。
很多安全问题并不是因为 SQLScript 本身不安全,而是因为程序把原本属于数据的数据,拼进了 SQL 语法结构。
理解这一点之后,Escape Code这个看起来