DB2无内置SQL注入防护，需应用层实现参数化查询、最小权限账户、错误信息脱敏及输入长度校验。
DB2 本身不提供“开箱即用”的 SQL 注入防护开关，所谓“启用内置安全保护机制”是个常见误解——DB2 不会自动过滤或拦截含恶意字符的参数。真正的防护必须由应用层主动实现，DB2 只负责执行你传给它的语句。
DB2 的预编译语句（ibm_db.prepare）为什么能防注入
预编译不是 DB2 的“防御功能”，而是它对 SQL 语法和参数的严格分离机制：SQL 模板在准备阶段被解析并固化执行计划，后续绑定的参数只作为数据值代入，绝不会参与语法解析。
- 即使你传入
"admin'; DROP TABLE users; --"，DB2 也只会把它当做一个完整字符串去匹配username字段，不会切分、不会执行分号后的语句 -
ibm_db.bind_param()之后调用ibm_db.execute()，底层走的是 DB2 的 CLI 接口，参数经类型校验后以二进制方式传递，绕过文本解析环节 - 注意：必须全程使用
?占位符，不能在 SQL 字符串里拼接任何用户输入，哪怕只是表名或排序字段
DB2 连接账户权限必须按最小化配置
DB2 不会阻止你用高权限账号执行恶意语句——如果攻击者通过其他漏洞（如未授权 API）拿到了执行入口，一个 dbadm 账号等于直接交出数据库控制权。
- 生产环境禁止使用
dbadm或sysadm连接应用，应单独创建角色如app_reader - 用
GRANT SELECT ON TABLE schema.table TO ROLE app_reader显式授权，避免GRANT SELECT ON SCHEMA这类宽泛授权 - 对写操作接口，另建
app_writer角色，且禁用DROP、CREATE、ALTER等 DDL 权限
DB2 的错误信息泄露是典型突破口
DB2 默认错误（如 SQL0104N、SQL0206N）会暴露表名、列名甚至片段 SQL，攻击者可据此构造更精准的注入 payload。
- 应用层必须捕获
ibm_db.exec_immediate()或ibm_db.execute()抛出的异常，统一返回模糊提示（如“查询失败，请稍后重试”） - 禁用 DB2 的
SQLCODE和SQLSTATE直接透出到前端，尤其避免在调试模式下开启db2set DB2OPTIONS=+v - 日志中记录完整错误时，确保敏感字段（如密码字段名、加密列名）不被明文写入
真正容易被忽略的点是：DB2 的 SQL 语句长度限制（默认 2 MB）和参数个数上限（MAXIMUM NUMBER OF PARAMETERS）可能被盲注利用——攻击者用超长 payload 触发截断或资源耗尽，从而绕过参数化逻辑。这类边界情况必须在应用层做长度预检，不能依赖 DB2 自动兜底。
