显然，如果我使用 JDBC/ODBC，我可以使用绑定变量和准备好的语句来防止 SQL 注入。但是，当数据被传递到最终调用 Oracle SQLPlus 的批处理时，有没有办法防止 SQL 注入？例如：
查询.sql：
select '&1' from dual;
exit;
如果我这样从 SQLPlus 调用这个脚本：
$ sqlplus SCOTT/TIGER @query.sql "x','y"
我将得到以下输出：
old 1: select '&1' from dual
new 1: select 'x','y' from dual
' '
- -
x y
如您所见，SQLPlus 命令行参数使用简单的宏替换。有没有我想念的替代方法？否则，我如何防止它被利用？
如果人们对您的数据库具有 sql*plus 访问权限，并且您在脚本中拥有特权用户的用户 ID 和密码供他们阅读，那么无论如何您都只是把裤子丢给了他们。SQL 注入是您最不必担心的。
通过命令行通过 SQL*Plus 传递参数将不仅仅是 SQL 注入，因为命令行将首先通过操作系统进行解释。因此，您还需要考虑操作系统用户可能执行的操作。
就个人而言，我会放弃 SQL*Plus 并使用 Perl 之类的东西。您有一种适当的编程语言来包装您的 SQL 语句，并且可以更好地处理变量和异常。
我建议改用绑定变量。在您的脚本中，您应该能够执行以下操作：
variable my_var varchar2(100);
begin
:my_var := &1;
end;
/
select :my_var from dual;
“my_var”变量将绑定到查询。而不是简单的查找/替换。
除非您将 SQL*Plus 脚本暴露给 Internet 上的恶意陌生人，否则您不会真正受到 SQL 注入攻击。真正会攻击你公司的人。
看来您是在谈论内部运行的批处理作业；完全在防火墙后面，其余的网络用户是你的同事，对吗？
除非他们是非常疯狂的反社会者，否则“攻击”没有任何意义。任何确实出现的 SQL 注入问题要么是非常糟糕的设计，要么是终止的原因。这只是对人们的访问权限和他们使用可用工具的技能的普通管理。
编辑
虽然我不能假装知道“由于控制字符造成的损坏”是什么意思，但我可以提供一些额外的建议。
如果你怀疑你可能有一个编程问题——通过 SQL 注入——会导致运行时中断，那么你需要一个测试环境。
克隆您的生产模式以制作测试模式。加载已知的数据子集。在测试模式上运行您的 SQL 脚本。如果您“以某种方式”将“控制字符”放入您的 SQL 脚本中，您将有一个测试脚本来演示这一点。
您可以使用以下 SQL Plus 命令：
SET DEFINE OFF