ABAP Keyword Documentation →  ABAP - Security Notes →  Security Risks Caused by Input from Outside →  SQL Injections 

SQL Injections Using Generic Programming

Generic programming is the most unsafe of all dynamic programming techniques. In principle, the ABAP command injections cover all individual security risks that can occur in dynamic programming, and most significantly SQL injections. The more generic the programming, the more difficult it is to prevent SQL injections from exploiting input that originates outside the program.

Other versions: 7.31 | 7.40 | 7.54

Example

The following program section demonstrates static embedded of Native SQL in a program generated using GENERATE SUBROUTINE POOL. Before ADBC was introduced, this was the only way of creating dynamic parts in Native SQL. In the case in question, the input key must be escaped using the method ESCAPE_QUOTES of the class CL_ABAP_DYN_PRG to prevent SQL injections. In a more realistic example, of course, host variables would be the preferred method.

DATA source TYPE TABLE OF string WITH EMPTY KEY. 
source = VALUE #( 
  ( `PROGRAM.` ) 
  ( `FORM exec_sql CHANGING name TYPE string.` ) 
  ( `  EXEC SQL.` ) 
  ( `    SELECT carrname` ) 
  ( `           INTO :name` ) 
  ( `           FROM scarr` ) 
  ( `          WHERE mandt  = 'sy-mandt' AND` ) 
  ( `                 carrid = 'key'` ) 
  ( `  ENDEXEC.` ) 
  ( `ENDFORM.`                               ) ). 

DATA key TYPE string. 
cl_demo_input=>request( CHANGING field = key ). 
REPLACE `sy-mandt` IN TABLE source WITH sy-mandt. 
REPLACE `key` IN TABLE source 
              WITH cl_abap_dyn_prg=>escape_quotes( to_upper( key ) ). 

DATA name TYPE string. 
GENERATE SUBROUTINE POOL source NAME DATA(pool). 
IF sy-subrc = 0. 
  PERFORM exec_sql IN PROGRAM (pool) CHANGING name. 
ENDIF. 
cl_demo_output=>display( name ).