SQL 注入是一种代码注入技术，攻击者通过在查询中注入恶意 SQL 代码，以此改变查询的原始意图。这可能导致未授权的数据访问、数据篡改、甚至数据丢失。
在 SAP ABAP 中，SQL 注入的风险主要来自于动态构造的 SQL 语句。ABAP 提供了 Open SQL 和 Native SQL 两种方式来访问数据库，其中 Open SQL 提供了一种与数据库无关的方式，而 Native SQL 则允许直接使用特定数据库的 SQL 语法。虽然 Open SQL 提供了一些安全性的保障，但如果不正确地使用，也可能导致 SQL 注入的风险。
以下是一个具体的例子：
假设我们有一个函数，它接受一个参数并根据该参数从数据库中获取数据：
FORM get_data USING p_id TYPE string.
DATA: lv_sql TYPE string.
CONCATENATE `SELECT * FROM sflight WHERE carrid = '` p_id `';` INTO lv_sql.
EXECUTE lv_sql.
ENDFORM.
这里，我们直接将用户提供的参数 p_id 拼接到 SQL 语句中。如果用户提供了一个正常的参数，例如 AA，那么生成的 SQL 语句将是 SELECT * FROM sflight WHERE carrid = 'AA';，这是完全正常的。然而，如果用户提供了一个恶意的参数，例如 AA'; DROP TABLE sflight; --，那么生成的 SQL 语句将是 SELECT * FROM sflight WHERE carrid = 'AA'; DROP TABLE sflight; --';。这个 SQL 语句实际上包含了两个语句：一个是正常的 SELECT 语句，另一个是 DROP TABLE 语句。执行这个 SQL 语句将会删除 sflight 表，这显然是一个严重的安全问题。
为了防止 SQL 注入，我们需要对用户提供的参数进行验证，确保它们不包含任何恶意的 SQL 代码。ABAP 提供了一些函数和方法可以帮助我们完成这项工作，例如 CL_ABAP_DYN_PRG=>ESCAPE_FOR_SQL。以下是一个改进的例子：
FORM get_data USING p_id TYPE string.
DATA: lv_sql TYPE string.
DATA: lv_id TYPE string.
CALL METHOD cl_abap_dyn_prg=>escape_for_sql
EXPORTING
unescaped = p_id
RECEIVING
escaped = lv_id.
CONCATENATE `SELECT * FROM sflight WHERE carrid = '` lv_id `';` INTO lv_sql.
EXECUTE lv_sql.
ENDFORM.
这里，我们使用了 CL_ABAP_DYN_PRG=>ESCAPE_FOR_SQL 方法对用户提供的参数进行转义，这样就可以防止大多数 SQL 注入攻击。需要注意的是，虽然这种方法可以提高安全性，但并不能防止所有的 SQL 注入攻击，因此还需要结合其他的安全措施，例如使用参数化的查询来限制。