Get Example source ABAP code based on a different SAP table
ARTICLE
System Command Injections A system command injection is a attack method on insufficiently secure dynamic programming. A System Command Injection forwards malicious operating system statements, which enter a program from an external source, to the operating system. In ABAP, this can occur when the following dynamic programming techniques are used:
Dynamic specification of the operating system statement after the FILTER addition of the OPEN DATASET statement.
Dynamic statement of the operating system statement for the CALL 'SYSTEM' statement. Here the internal statement CALL calls a special system function (SYSTEM), which can be used to execute operating system statements. The two ways shown here of executing operating system statements are very insecure (even with no external input) and should be avoided in ABAP programs. Calls of the SYSTEM function should be especially avoided and can be deactivated using the profile parameter rdisp/call_system. External statements or parts of external statements should never be passed to the operating system without being checked first. If operating system statements have to be executed, then this should be carried out using function modules from the function group SXPG such as SXPG_CALL_SYSTEM or SXPG_COMMAND_EXECUTE. The permitted operating system statements then have to be entered in a whitelist using transaction SM69. Authorization checks and other checks are then performed. Transaction SM49 is used to display the permitted operating system statements. Even when these function modules are used, any external input entries that are passed to the parameters should be checked, in order to prevent the unwanted execution of operating system statements.
Example In the following program section, the operating system statement ping is executed for the current database server using the unwanted system function SYSTEM. If this function has been deactivated (using the profile parameter rdisp/call_system), a runtime error occurs. The number of 'pings' can be set externally. To prevent a 'denial of service' attack, the number is restricted to a maximum of 10. TYPES char255 TYPE c LENGTH 255.
DATA dbserver TYPE char255. CALL 'C_SAPGPARAM' ID 'NAME' FIELD 'SAPDBHOST' ID 'VALUE' FIELD dbserver.
DATA pings TYPE i VALUE 1. cl_demo_input=>request( CHANGING field = pings ).
DATA command TYPE char255. DATA result TYPE TABLE OF char255 WITH EMPTY KEY. command = |ping -c{ COND i( WHEN pings <(><<)>= 1 THEN 1 WHEN pings >= 10 THEN 10 ) } { dbserver }|. CALL 'SYSTEM' ID 'COMMAND' FIELD command ID 'TAB' FIELD result. cl_demo_output=>display( result ).
Example In the following program section, the unwanted use of system function SYSTEM is replaced by calling function module SXPG_CALL_SYSTEM. Here the parameter is also set externally and no denial of service attack occurs. The function module call only shows some of the possible exceptions. TYPES char255 TYPE c LENGTH 255.
DATA dbserver TYPE char255. CALL 'C_SAPGPARAM' ID 'NAME' FIELD 'SAPDBHOST' ID 'VALUE' FIELD dbserver.
DATA pings TYPE i VALUE 1. cl_demo_input=>request( CHANGING field = pings ).
DATA result TYPE TABLE OF btcxpm WITH EMPTY KEY. DATA parameters TYPE char255. parameters = |-c{ COND i( WHEN pings <(><<)>= 1 THEN 1 WHEN pings >= 10 THEN 10 ) } { dbserver }|. CALL FUNCTION 'SXPG_CALL_SYSTEM' EXPORTING commandname = 'PING' additional_parameters = parameters TABLES exec_protocol = result EXCEPTIONS no_permission = 1 command_not_found = 2 security_risk = 3 OTHERS = 4. IF sy-subrc = 0. cl_demo_output=>display( result ). ELSE. cl_demo_output=>display( |Error, return code { sy-subrc }| ). ENDIF.
