ABAP OPEN SQL注入：你可能每天都在踩的坑
先别急着说“我代码写得规范，肯定没事”。去年我帮一家制造企业做系统优化，翻他们的老代码时，发现近30%的OPEN SQL查询都藏着注入隐患。你可能觉得“我们内部系统，哪有黑客来搞事”，但别忘了，权限越界的员工、配置错误的接口，甚至第三方集成的数据，都可能变成“攻击源”。
到底啥是OPEN SQL注入？
就是黑客通过篡改输入数据，让你的SQL查询执行意外的命令。ABAP里的OPEN SQL虽然比Native SQL安全一些（有自动转义），但如果用不对，照样会出问题。举个例子：你写了个查询物料的代码，想根据用户输入的物料号过滤，结果写成了这样：
DATA(lv_matnr) = sy-uname. " 假设这里是用户输入的物料号
SELECT FROM mara INTO TABLE @DATA(lt_mara)
WHERE matnr = '&&lv_matnr'. " 注意这里用了字符串拼接
看着眼熟不？如果用户输入的不是正常物料号，而是 ' OR '1'='1，这行代码就会变成 WHERE matnr = '' OR '1'='1'——结果就是把整个MARA表的数据都查出来了！这还只是查，如果是UPDATE或DELETE语句，后果不堪设想。
最容易踩坑的3种场景
你可能觉得“我才不会犯这种低级错误”，但实际开发中，这些场景特别容易中招：
WHERE matnr LIKE '%' && lv_input && '%'，结果用户输入 %' OR '1'='1我之前遇到个极端案例：有家公司的ABAP开发为了方便，把用户输入的“部门名称”直接拼进了查询成本中心的SQL里。结果一个离职员工用旧账号登录，输入 ' OR kokrs = '1000（公司总部控制范围），直接把全公司的成本数据扒了下来。
不安全代码vs安全代码，一眼看穿
为了让你更直观，我整理了3种常见错误写法和对应的安全写法，你可以对照着检查自己的代码：
| 场景 | 不安全写法（风险） | 安全写法（防御） |
|---|---|---|
| 简单查询 | WHERE matnr = ‘&& lv_input’（直接拼接变量） | WHERE matnr = @lv_input（使用绑定变量@） |
| 模糊查询 | WHERE matnr LIKE ‘%’ && lv_input && ‘%’（拼接通配符） | lv_input = ‘%’ && lv_input && ‘%’; WHERE matnr LIKE @lv_input（变量绑定通配符） |
| 动态SQL | CONCATENATE ‘SELECT FROM mara WHERE matnr = ”’ && lv_matnr && ”” INTO lv_sql. EXECUTE IMMEDIATE lv_sql. | EXECUTE IMMEDIATE ‘SELECT FROM mara WHERE matnr = @1′ INTO lt_result USING lv_matnr.（参数化动态SQL） |
你看，右边的安全写法其实就多了个 @ 符号或 USING 子句，但安全性天差地别。SAP官方在《Secure ABAP Coding》中明确提到，所有用户输入必须经过验证和参数化处理才能用于SQL查询（SAP Help Portal）。
手把手教你防御：从代码到实战
知道了坑在哪，接下来就教你怎么防。这几年我帮十几家客户做过ABAP安全审计， 出4个“笨办法”，不用记复杂理论，照着做就能大幅降低风险。
方法一：绑定变量@——最简单也最有效
你可能听过“参数化查询”，在ABAP里其实就是用 @ 符号把变量绑定到SQL语句中。别小看这个符号，它能让ABAP自动处理特殊字符转义，相当于给SQL查询加了道“防火墙”。
比如刚才那个物料查询的例子，安全写法应该是：
DATA(lv_matnr) = user_input. " 用户输入的物料号
SELECT FROM mara INTO TABLE @DATA(lt_mara)
WHERE matnr = @lv_matnr. " 用@绑定变量，ABAP会自动转义
这里的 @lv_matnr 会告诉ABAP：“这是个参数，不是SQL命令的一部分”，就算用户输入带引号、OR这些特殊字符，ABAP也会把它们当成普通文本处理。我去年帮一个客户改代码，就把所有直接拼接的地方换成了 @ 绑定，结果安全扫描的高危漏洞直接降了70%。
关键技巧
：就算是内部系统、固定值，只要涉及用户输入（包括前端输入、接口参数、甚至配置表数据），都用 @ 绑定。别嫌麻烦，这是性价比最高的防御手段。
方法二：输入验证——给数据加道“安检”
绑定变量能防大部分问题，但如果用户输入的根本不是“物料号”，比如输了个100位的字符串，就算不注入，也可能导致查询效率低下或报错。这时候就需要“输入验证”——提前检查数据的合法性。
你可以按这3步来：
^[A-Z0-9]{10}$ 只允许字母和数字举个例子，验证物料号的代码可以这么写：
" 检查长度
IF strlen(lv_matnr) >
MESSAGE '物料号不能超过18位' TYPE 'E'.
ENDIF.
" 检查格式（只允许字母、数字和横线）
IF lv_matnr NOT MATCHES '^[A-Z0-9-]+$'.
MESSAGE '物料号只能包含字母、数字和横线' TYPE 'E'.
ENDIF.
我之前遇到个客户，他们的销售订单查询允许用户输入客户编号，结果有人输了 ' OR kunnr LIKE '000% 想查所有客户数据。后来加了验证：客户编号必须是10位数字，非法输入直接报错，问题就解决了。
方法三：动态SQL别任性——用REPLACE和绑定变量组合
有时候你需要动态拼接SQL（比如根据不同条件组合WHERE子句），这时候直接拼接字符串就很危险。教你个安全写法：先用占位符 {0} {1} 定义动态部分，再用 REPLACE 函数替换，最后用 @ 绑定变量。
比如动态查询成本中心：
" 定义动态WHERE子句模板，用{0}做占位符
DATA(lv_where) = 'AND kokrs = {0} AND kcost LIKE {1}'.
" 替换占位符为绑定变量（注意用@）
REPLACE '{0}' IN lv_where WITH '@lv_kokrs'. " 控制范围
REPLACE '{1}' IN lv_where WITH '@lv_kostl_pattern'. " 成本中心模糊查询条件
" 执行动态SQL，用@绑定变量
EXECUTE IMMEDIATE 'SELECT * FROM csks WHERE mandt = @sy-mandt ' && lv_where
INTO TABLE @DATA(lt_csks)
USING @lv_kokrs @lv_kostl_pattern. " 按顺序传入变量
这里的关键是：动态部分只拼“SQL结构”（比如字段名、条件关键字），具体值永远用 @ 绑定。SAP官方在《Dynamic SQL in ABAP》中特别强调，动态SQL必须避免拼接用户输入的具体值（SAP Help Portal）。
方法四：权限控制+审计——最后一道防线
前面说的都是技术层面，其实“权限控制”才是根本。就算SQL查询被注入，如果用户没有查询MARA表的权限，也查不出数据。你可以从这两方面入手：
我之前有个客户，虽然代码有注入风险，但因为权限控制严格，普通用户只能查自己部门的数据，就算注入成功，也拿不到敏感信息。所以别光盯着代码，权限和审计也要跟上。
实战小技巧
：写完代码后，用SU53检查权限对象是否生效，再用SE16N测试不同权限用户的查询结果，确保“该看的能看，不该看的看不到”。
你按这些方法改完代码后，可以用ABAP Test Cockpit（ATC）的安全检查功能扫一遍，它会帮你找出潜在的注入风险。如果扫出来还有问题，或者你遇到其他场景，欢迎在评论区告诉我，咱们一起看看怎么解决。记住，安全不是一次性的事，多踩坑、多 才能写出更健壮的ABAP代码。
动态SQL拼接条件这事儿，你肯定遇到过——比如用户选了不同的筛选条件，你得动态加WHERE子句，或者根据权限显示不同的字段。这时候最容易犯的错就是“顺手把用户输入的具体值直接拼进去”，比如用户选了部门A，你就写' AND dept = ''' && lv_dept && ''''，看着简单，其实等于给注入留了后门。我之前帮一个客户看代码，就见过有人为了省事，把前端传的“排序字段”直接拼进SQL，结果用户输入' OR 1=1 ORDER BY salary DESC ，直接把全表数据按薪资倒序查出来了，吓出一身冷汗。
正确的做法得把“SQL结构”和“具体数值”分开。你可以先拿占位符（比如{0}、{1}）当“位置标记”，把要拼接的条件框架搭起来，比如'AND dept = {0} AND cost_center LIKE {1}'。这里的{0}和{1}就像空座位，专门留给后面要传的参数。然后用REPLACE函数把这些占位符换成带@的变量，比如把{0}换成@lv_dept，{1}换成@lv_cc_pattern，这样SQL语句就变成了'AND dept = @lv_dept AND cost_center LIKE @lv_cc_pattern'。最后执行的时候，用USING子句把具体的数值传进去，比如EXECUTE IMMEDIATE ... USING @lv_dept @lv_cc_pattern。这么一来，ABAP就知道“@lv_dept这些是参数，不是SQL命令的一部分”，就算用户输入里有引号、OR这些特殊字符，也只会被当成普通文本处理。
我去年帮一家零售客户改代码，他们有个动态查询订单的功能，之前总被安全扫描报“SQL注入风险”。我就是用这个办法，把所有拼接的具体值都换成了占位符+@变量，结果扫描直接从“高危”变成“低危”，开发还说“代码看着反而更清爽了，不用记那么多引号拼接规则”。记住，动态拼接只拼“字段名、逻辑关键字”这种固定结构，具体的数值永远用@变量传——这招亲测能避开90%的动态SQL注入坑。
ABAP OPEN SQL和Native SQL的注入风险有什么区别？
OPEN SQL是ABAP专用的SQL方言，会自动对部分特殊字符进行转义，且仅支持SAP数据库对象，注入风险相对较低；而Native SQL直接执行数据库原生SQL语句，没有自动转义机制，注入风险更高。但需注意，OPEN SQL若使用字符串拼接变量，仍可能存在注入隐患，需通过@绑定变量等方式防御。
使用@绑定变量后，还需要做输入验证吗？
需要。@绑定变量主要防止SQL注入攻击，但无法解决输入数据本身的合法性问题（如超长字符、格式错误等）。输入验证（如长度检查、格式校验）可进一步确保数据符合业务规则，减少无效查询或系统异常，两者结合能提升代码健壮性。
动态SQL必须拼接条件时，如何确保安全？
动态SQL拼接时，应仅拼接SQL结构（如字段名、逻辑关键字），具体参数值需通过@绑定变量传入。可先用占位符（如{0}）定义动态部分，再用REPLACE函数替换为@变量，最后通过USING子句传入参数，避免直接拼接用户输入的具体值。
如何快速检查现有代码中的注入漏洞？
可使用ABAP Test Cockpit（ATC）的安全检查功能，启用“SQL注入风险”相关检查规则（如“未使用参数化查询”），系统会自动扫描代码中字符串拼接SQL、未绑定变量等风险点。 可重点检查包含“&&”字符串拼接、动态SQL构造的代码段，人工复核潜在隐患。
权限控制严格的系统，还需要防御SQL注入吗？
需要。权限控制是安全的最后一道防线，但无法完全替代SQL注入防御。 高权限用户可能恶意构造输入，或存在权限配置疏漏，导致越权查询；且注入攻击可能导致查询性能下降、数据异常等问题。 即使权限严格，仍需通过绑定变量、输入验证等手段从代码层面防御。
