Comments
SAP SQL INJ GEN PROG SCRTY documentation, setup help and example usage
ARTICLE
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
. The more generic the programming, the more difficult it is to prevent SQL injection s from exploiting input that originates outside the program.
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 injection s. 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 ).
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved
