ABAP Keyword Documentation → ABAP - Security Notes → Further Security Risks
User-Dependent Program Flow
The use of user names in ABAP programs to control program behavior can be a security risk. In the worst case scenario, a back door can be created and used by developers to access unauthorized data or functions in systems where they do not have authorization. On the other hand, these can also be code sections used for test purposes during development and then forgotten. Generally speaking, user-dependent source code should always be avoided and removed if necessary. In cases where user-dependent source code is absolutely necessary, a special exemption must be granted for the program so that it can pass the appropriate security tests.
In ABAP, user-dependent program flows can occur in the following instances:
- The system field sy-uname is queried in logical expressions. This is a security risk and should never occur (with the exception of a few predefined user names).
- A user name specified using the addition
USERof the statement
AUTHORITY-CHECK. This addition can be misused to bypass an authorization check by specifying a user with extensive authorizations. The same applies to function modules such as AUTHORITY_CHECK or SU_RAUTH_CHECK_FOR_USER, which do not usually need to be used locally. It may, however, be useful to call these function modules using RFC, to inspect the authorizations of the current user of the local system in remote systems.
sy-uname is usually redundant when specified explicitly after the addition
USER and carries the risk of the content being manipulated in advance, for example in ABAP Debugger.
User names passed to the program from the outside should never be used. If this does become necessary, however, the names must be checked carefully.
7.31 | 7.40 | 7.54
- If the current user name is required in a program, it is safer to determine it used the method GET_USER_NAME
of the class CL_ABAP_SYST than taking it from the system field
sy-uname, which is easier to manipulate.
- Specifying a user name using the addition
USERof the statement
SUBMIT VIA JOBis not a security risk, since this name is checked for the current user using the authorization object S_BTCH_NAM.
The following program section demonstrates a back door where an authorization check for a user is ignored
intentionally. The program must be repaired by removing the
IF control block with the
ID 'DEVCLASS' FIELD '...'
ID 'OBJTYPE' DUMMY
ID 'OBJNAME' DUMMY
ID 'P_GROUP' DUMMY
ID 'ACTVT' FIELD '02'.
IF sy-subrc <> 0.
IF sy-uname <> '...'.
This translation does not reflect the current version of the documentation.