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.
7.31 | 7.40 | 7.54
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 ).
This translation does not reflect the current version of the documentation.