ARTICLE
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 USER of 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.
A user name specified using the addition USER of the statement
SUBMIT VIA JOB . It can be misused to
execute a program with more extensive authorizations than the user
actually has.
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.
Note
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.
Example
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
sy-uname query.
AUTHORITY-CHECK OBJECT 'S_DEVELOP'
ID 'DEVCLASS' FIELD '...'
ID 'OBJTYPE' DUMMY
ID 'OBJNAME' DUMMY
ID 'P_GROUP' DUMMY
ID 'ACTVT' FIELD '02'.
IF sy-subrc <(><<)>> 0.
IF sy-uname <(><<)>> '...'.
LEAVE PROGRAM.
ENDIF.
ENDIF.
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved