ABAP Code Injection
Code injection is one of the simplest, yet most pervasive, types of cyberattacks hackers use. In this article, you'll learn how to defend against ABAP code injections.
Join the DZone community and get the full member experience.Join For Free
We continue describing categories from the list that we discussed in our Introduction to Secure ABAP Development Guide and pursue "Injections," a type of vulnerability that occurs when an application provides no or bad user input validation. An attacker can inject malicious data, thus performing non-intended actions in a system. Such vulnerability may result in the major SAP risks (Espionage, Sabotage, and Fraud).
Among other things, in ABAP programs, ABAP code itself can be directly injected. It can be done via "INSERT REPORT" and "GENERATE SUBROUTINE POOL" statements. For example:
INSERT REPORT Example
TYPES: source_line(72) TYPE c. DATA: src TYPE TABLE OF source_line, prg_name type string value 'ZGENPROG'. PARAMETERS: u_input(72) TYPE c. APPEND u_input TO src. INSERT REPORT prg_name FROM src. SUBMIT (prg_name) AND RETURN.
An attacker can pass malicious code to "u_input parameter" and then execute it. Also, the statement "INSERT REPORT" can pose another danger in case a user input is used to generate a program name. If an attacker knows the name of a critical program, he or she can rewrite its source code by passing the necessary name to the "prg_name" parameter.
GENERATE SUBROUTINE POOL Example
TYPES: source_line(72) TYPE c. DATA: src TYPE TABLE OF source_line, prg_name TYPE string. PARAMETERS u_input(72) TYPE c. APPEND u_input TO src. GENERATE SUBROUTINE POOL src NAME prg_name.
In this example, the ABAP code from an untrusted source is passed to the subroutine "prg_name" and then executed.
If an unfiltered user input passes to statements "INSERT REPORT" and "GENERATE SUBROUTINE POOL" properly, an attacker can execute arbitrary code, which will lead to different security threats such as reading any business-critical information, including HR data or credit cards, as well as executing any malicious code on the server.
Additionally, an attacker can inject ABAP code in a message log via 'BAL_LOG_MSG_ADD' and thus hide the traces of compromising the system.
Avoid using a dynamic program generation tool or use whitelists to restrict access to specific programs or functionalities. As we discussed in the previous post, CHECK_WHITELIST_STR and CHECK_WHITELIST_TAB methods of CL_ABAP_DYN_PRG class will help you do so:
TYPES whitelist TYPE HASHED TABLE OF string WITH UNIQUE KEY table_line. PARAMETERS p_input TYPE string. DATA(whitelist) = VALUE whitelist( ( `STRING1` ) ( `STRING2` ) ( `STRING3` ) ). TRY. p_input = cl_abap_dyn_prg=>check_whitelist_tab( val = to_upper( p_input ) whitelist = whitelist ). CATCH cx_abap_not_in_whitelist. cl_demo_output=>write( `Only the following strings are allowed:` ). cl_demo_output=>display( whitelist ). LEAVE PROGRAM. ENDTRY.
The whitelist here contains values
'STRING3' - the list of allowed lines of code.
This is all for today and we hope the article has clarified all your questions about ABAP Code injections. Stay tuned and we'll consider HTTP Header injection in the next post.
Published at DZone with permission of Alexander Polyakov, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.