ABAP Keyword Documentation →  ABAP - Security Notes → 

Security Risks in Dynamic Programming

Most security problems encountered in ABAP programs are caused by incorrectly or carelessly used dynamic programming techniques. Security risks arise here whenever full statements, parts of statements, or objects accessed in statements are specified dynamically and hence are not subject to static checks. Two main cases must be distinguished here:

If assuming that the developer of a program does so without malicious intent, dynamic programming techniques are uncritical in the former case. Here, information is specified dynamically, for instance, to make the programming of functions more compact than if they were programmed statically.

The latter case, on the other hand, is critical. If external input is specified dynamically in an ABAP statement without being checked or masked, damage can be incurred (whether unintentional or malicious). The damage can range from exceptions being raised, the absence of system resources ("Denial of Service" attacks), to the manipulation of persistent data.

The following sections provide examples of the most significant security risks encountered when using dynamic programming techniques together with external input:

The global principle in these sections of always checking and/or masking external input also applies in all cases not listed separately here, such as using a dynamic WHERE condition when accessing internal tables.

Note

Back doors, implemented by malicious developers using dynamic programming techniques, are not discussed here. These cannot be checked statically, since they do not originate outside the program, and are not usually classified as dangerous by static checks. The two-man rule code inspections are probably the only solution here. See also Obscuring ABAP Source Code.




Continue
SQL Injections
Dynamic Calls
Directory Traversal
System Command Injections
Cross Site Scripting
ABAP Command Injections