Skip to Content

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.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Thomas WÜRCHER

    You’ re adressing a very big topic here. As far as I see ABAPers often regard their systems as secure just by the fact that they have a restricted user group, only run in Intranet and there’ s a virus scanner anyway. But with all these web and mobile technologies I’ m sure there has more attention to be paid on issues like the one you describe.

    (0) 
  2. Andreas Wiegenstein

    Hi Horst,

    What you describe here is just the tip of the iceberg.

    Everyone fluent in German looking for comprehensive information on ABAP security should read “Sichere ABAP Programmierung” (SAP Press 2009).

    At BIZEC you can find the list of the most common and the most critical security defects in ABAP: http://www.bizec.org/wiki/BIZEC_APP11

    Technical side-note: I discourage the use of CL_ABAP_DYN_PRG=>ESCAPE_QUOTES.

    It’s safer to use CL_ABAP_DYN_PRG=>QUOTE, since this avoids potential confusion regarding the contextually correct quotation marks.

    (0) 
  3. Muthukumar Pasupathy

    Hi Horst,

    I would like to add one more point regarding the use of CALL TRANSACTION ‘tcode’ statement. This does not check if the current user has the authorization to execute the transaction – “tcode”. To avoid this problem, the CALL TRANSACTION statement may be replaced by the Function Module: ABAP4_CALL_TRANSACTION. This FM does the authorization checks internally. All the additions possible with CALL TRANSACTION statement are available with this FM also (as parameters).

    (0) 
    1. Horst Keller Post author

      Hi,

      Thanks for notifying. With Release 7.40, it will be even better. There is a new addition WITH AUTHORITY-CHECK to the CALL TRANSACTION STATEMENT, that replaces the usage of self programmed checks for that statement. With the addition, CALL TRANSCATION is checked in  the same way as LEAVE TO TRANSACTION. Usage of CALL TRANSCATION without that addition is declared as obsolete …

      (0) 
    2. Andreas Wiegenstein

      Hi Muthukumar,

      the function module ABAP4_CALL_TRANSACTION does exactly what you describe and is working fine security-wise.

      However, in my practical experience many SAP customers don’t use it for the simple reason that it has not been released…

      (0) 

Leave a Reply