如本文所示，DB2 可能容易受到 SQL 注入的攻击：
* Potential SQL injection if X, Y or Z host variables come from untrusted input
STRING "INSERT INTO TBL (a,b,c) VALUES (" X "," Y "," Z ")" INTO MY-SQL.
EXEC SQL PREPARE STMT FROM :MY-SQL END-EXEC.
EXEC SQL EXECUTE STMT END-EXEC.
我的问题是本机 IMS 命令是否容易受到这种（或类似）注入的攻击？例如，通过在ISRT DLI 命令中输入恶意输入。
这取决于您计划如何访问 IMS 数据库。
引用IBM 文档。
您通过 Web 界面或 ISPF 界面发出的 SQL 语句在 z/OS® 中的 IMS SPUFI 应用程序中作为 IMS 应用程序编程 API 执行。您可以选择 COBOL 或 Java™ 作为语言环境来执行 SQL 语句。
如果您使用 SQL，您可能容易受到 SQL 注入的攻击。
如果您使用本机 IMS 命令，可能不会。但是清理输入仍然是一个好主意，即使对于本机 IMS 命令也是如此。
不，IMS DL/I 数据库根本不解析记录。将其视为像 Cassandra 这样的 NoSQL 数据库的早期版本。段键被解析为二进制值，但您不能像在 SQL 数据库中那样进行注入。
并且根据程序员/IMS 管理员的技能，可以通过使用 PSB 中 PCB 的 PROCOPT 限制程序可用的可用 CRUD 操作的范围来关闭攻击向量。
大多数 IMS-system+DB2 使用静态 SQL，因此语句已经准备好，不易受到 SQL 注入攻击。
我是 IBM IMS 团队的成员。
IMS DL/I 调用不是动态的，因此不像 SQL 调用那样容易受到影响。CALL xxxTDLI IMS API 没有注入风险。话虽如此，COBOL 程序可以通过允许对程序的输入影响传递给 xxxTDLI 的 SSA 列表或 IOAREA 参数来打开风险。因此，在针对这些接口进行编程时，应遵循安全的工程实践。
是的，所有支持运行时解析 SQL 查询字符串的 SQL 数据库都容易受到 SQL 注入的影响。
SQL 注入不是数据库技术中的缺陷，而是您编写的用于构建 SQL 查询字符串的客户端代码中的缺陷。