ABAP and Security – My 2 Cents

Security of ABAP programs is an important subject. In this blog I try to drill it down to some basic facts. This blog is for responsible developers who want to protect their ABAP code against attacks.

As a responsible developer you must prevent mainly two security risks:

• Insufficient Authority Checks

  Sufficient security checks make up an important ingredient of secure ABAP code. You are responsible for all accesses to sensible data or functionality that occur  inside your programs. You have to take care that only authorized users can execute such parts of your program.  Either your whole program is restricted to authorized users, you rely on implicit authority checks (as e.g. for LEAVE TO TRANSACTION) or you have to program an AUTHORITY-CHECK yourself (e.g. in front of CALL TRANSACTION).  If you program your own authority checks, of course you must know what and how to check. Good for you, if you can simply ask your system administrator. Otherwise, you have to grapple with the SAP authority concept involving authority objects, roles, profiles, transaction SU24 and whatsoever yourself.

• Code Injections

  The most important vulnerability of ABAP programs to attacks from the outside arises from dynamic programming techniques that make use of uncontrolled input. If you use any data from outside your program (user input or data passed to formal parameters) as parts of statements or as objects accessed by statements, you must check and if applicable escape such input before using it to prevent one of the following risks:

     o SQL Injections
              Input from the outside is directly used in dynamic tokens of Open SQL or in statements passed to ADBC.

     o Dynamic Calls:
              Input from the outside is directly used in statements that call programs or procedures.

     o Directory Traversal
              Input from the outside is directly used in statements of the ABAP file interface.

     o System Command Injections
              Input from the outside is directly used as system commnad, .e.g. behind CALL ‘SYSTEM’.

     o Cross Site Scripting
              Input from the outside is directly used in HTML files for web pages.

     o ABAP Command Injections
              Input from the outside is directly used in generated ABAP code.

 
As a rule, you should restrict dynamic code that involves input from outside the program to the absolute necessary. If you have to work with that dangerous kind of code, the methods of class CL_ABAP_DYN_PRG and also the built-in function escape help you to check and escape input from the outside before using it in statements. Check tools for static code analysis can help in finding such positions.

Typical example: You must apply CL_ABAP_DYN_PRG=>ESCAPE_QUOTES to any input that you want to concatenate into a dynamic WHERE clause to prevent access to forbidden data:

PARAMETERS name TYPE string.
DATA cond type string.

cond = `country = ‘DE’ AND name = ‘` &&
       cl_abap_dyn_prg=>escape_quotes( name ) && `’`.
SELECT * FROM scustom
         INTO TABLE customers
         WHERE (cond).

Without escaping, an input like x’ OR name <> ‘ would select all data from SCUSTOM.

As a responsible ABAP programmer, you pay attention to these points and try to secure your code by checking authority and controlling any input from the outside. Malicious ABAP programmers do it another way around. They build back doors and try to obscure them. For example, if you find code, where the system field sy-uname is dynamically assigned to a field symbol and where this field symbol is then used to control the program flow, you might have found a back door where someone tried to obscure an user dependent program execution. The problem is, that a malicious programmer might always find a way to outwit a check tool. Therefore only code inspections or team programming might prevent such back doors.