APP.4.6 SAP ABAP Programming
Custom developments are frequently programmed in SAP systems. The reasons are varied — business processes or reporting requirements can be individually...
Description
Introduction
Custom developments are frequently programmed in SAP systems. The reasons are varied — business processes or reporting requirements can be individually adapted to the institution using custom developments. It is also possible to create special functions that are not available in the standard delivery.
Custom developments are programmed by the institution’s own developers or by contracted developers. In the SAP environment, ABAP (Advanced Business Application Programming) is frequently used for this purpose.
ABAP is a proprietary, platform-independent programming language developed by SAP. It was developed for programming commercial applications in the SAP environment and its basic structure bears a distant resemblance to COBOL. Important features include:
- Integration of an authentication, roles, and authorization concept,
- use of a proprietary, database-independent SQL derivative (Open SQL),
- support for communication between different SAP systems, and
- integration of audit options.
Objective
This building block identifies relevant technical risks for ABAP developers and security testers that can arise from ABAP custom developments. It also defines requirements that show how ABAP programs can be developed and used securely.
The building block assumes basic knowledge of ABAP and experience with ABAP development tools.
Scope and Modeling
The building block APP.4.6 SAP ABAP Programming must be applied once to each SAP system when custom developments in the ABAP programming language are created.
This building block extends the building blocks CON.8 Software Development, APP.6 General Software, and APP.7 Development of Custom Software with specific aspects of ABAP program development.
This building block is not a complete guide to developing ABAP programs, but rather describes the general risks of the ABAP programming language. The building block defines requirements that should be met from a security perspective when developing ABAP programs.
Since web applications make up only a very small proportion of all ABAP applications in SAP implementations, web vulnerabilities are not the focus of this document.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to represent the threat landscape. The following specific threats and vulnerabilities are of particular relevance for the building block APP.4.6 SAP ABAP Programming.
Missing Authorization Checks
In SAP, authorizations are only checked when a corresponding authorization check has been implemented in the program code by developers. Without such a check in the program code, it is not verified whether users are actually authorized to perform an action. In custom program code, however, authorization checks are frequently omitted. As a result, the entire authorization concept often does not take effect, and unauthorized persons can access data stored in the SAP system. This can also lead to violations of compliance requirements. This can have particularly serious consequences during financial audits.
Loss of Confidentiality or Integrity of Critical Data
SAP systems contain much institution-critical information. The SAP standard provides various mechanisms to protect this data. However, faulty ABAP custom developments could allow unauthorized access to institution-critical information. Employees or attackers could then transfer the data to an environment that can no longer be controlled. ABAP programs could also be used to manipulate critical data by circumventing the security mechanisms of the SAP standard.
Injection Vulnerabilities
Injection vulnerabilities arise when attackers inject control characters or commands into an application through an input field. A successful attack can disrupt the intended program flow through unexpected commands.
Injection vulnerabilities represent the greatest security risk for custom developments. Due to faulty code in an ABAP application, attackers may be able to completely control an SAP system in some cases. Since such attacks are very complex and have many variants, they are difficult to recognize and remediate without specialized training.
Circumvention of Existing SAP Security Mechanisms
The SAP standard provides various protection mechanisms for data, including client separation, identity management, as well as roles and authorizations. However, these security mechanisms can be deliberately circumvented or unintentionally omitted in code.
Requirements
The following are the specific requirements of the building block APP.4.6 SAP ABAP Programming. The Information Security Officer (ISO) is responsible for ensuring that all requirements are fulfilled and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.
Further roles are defined in the IT-Grundschutz Compendium. They should be filled insofar as this is reasonable and appropriate.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | Developers |
| Additional responsibilities | None |
Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people should fill these roles.
Basic Requirements
The following requirements MUST be fulfilled with priority for this building block:
APP.4.6.A1 Securing Reports with Authorization Checks (B)
It MUST be ensured that only authorized persons can start custom programmed reports. For this reason, every report MUST perform explicit authorization checks appropriate to the context.
APP.4.6.A2 Formally Correct Evaluation of Authorization Checks (B)
Every authorization check in the code MUST be evaluated by querying the return value SY-SUBRC.
APP.4.6.A3 Authorization Check Before Starting a Transaction (B)
When developers use the CALL TRANSACTION command, a start authorization check MUST always be performed beforehand.
APP.4.6.A4 Avoidance of Proprietary Authorization Checks (B)
Every authorization check MUST technically be performed using the dedicated command AUTHORITY-CHECK. Proprietary authorization checks, e.g. based on account identifiers, MUST NOT be used.
Standard Requirements
Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.
APP.4.6.A5 Creation of a Policy for ABAP Development (S)
A policy for the development of ABAP programs SHOULD be created. The policy SHOULD contain not only naming conventions but also specifications regarding ABAP elements that may or may not be used. The requirements from this building block SHOULD be incorporated into the policy. The policy SHOULD be binding for developers.
APP.4.6.A6 Complete Execution of Authorization Checks (S)
When performing an authorization check in ABAP code (AUTHORITY-CHECK ), it SHOULD be ensured that all fields of the relevant authorization object are checked. If individual fields are genuinely not needed, they SHOULD be marked as DUMMY. In addition, the reason for the exception SHOULD be documented at the field level.
APP.4.6.A7 Authorization Check During Input Processing (S)
Function codes and screen elements of ABAP Dynpro applications SHOULD be consistent. If a screen element has been deactivated, an application SHOULD NOT respond to events of that element without adequate authorization checks. If certain entries of a Dynpro menu are hidden or individual buttons are deactivated, the associated function codes SHOULD also not be executed.
APP.4.6.A8 Protection Against Unauthorized or Manipulative Access to the Filesystem (S)
If access to files on the SAP server depends on user input, this input SHOULD be validated before access.
APP.4.6.A9 Authorization Check in Remote-Capable Function Modules (S)
It SHOULD be ensured that all remote-capable function modules in the program code explicitly check whether the caller is authorized to execute the associated business logic.
APP.4.6.A10 Prevention of the Execution of Operating System Commands (S)
Every call to a permitted operating system command SHOULD be preceded by an appropriate authorization check (authorization object S_LOG_COM). User input SHOULD NOT be part of a command. For this reason, operating system calls SHOULD ONLY be executed via the dedicated SAP standard function modules provided for this purpose.
APP.4.6.A11 Avoidance of Injected Malicious Code (S)
The ABAP commands INSERT REPORT and GENERATE SUBROUTINE POOL SHOULD NOT be used.
APP.4.6.A12 Avoidance of Generic Module Execution (S)
Transactions, programs, function modules, and methods SHOULD NOT be generically executable. If there are important reasons for generic execution, it SHOULD be documented in detail where and why this occurs. In addition, an allowlist SHOULD be defined that contains all permitted modules. Before a module is called, user input SHOULD be compared against the allowlist.
APP.4.6.A13 Avoidance of Generic Access to Table Contents (S)
Table contents SHOULD NOT be generically read out. If there are important reasons for doing so, it SHOULD be documented in detail where and why this occurs. In addition, it SHOULD then be ensured that the dynamic table name is restricted to a controllable list of values.
APP.4.6.A14 Avoidance of Native SQL Statements (S)
The interface ABAP Database Connectivity (ADBC) SHOULD NOT be used. User input SHOULD NOT be part of ADBC commands.
APP.4.6.A15 Prevention of Data Leaks (S)
A sufficiently secure authorization check SHOULD be performed before business-critical data is displayed, transmitted, or exported. Intended (deliberate) export options SHOULD be documented.
APP.4.6.A16 Avoidance of System-Dependent Function Execution (S)
ABAP programs SHOULD NOT be programmed in a system-dependent manner such that they can only be executed on a specific SAP system. If this is strictly necessary, it SHOULD be documented in detail. In addition, the code SHOULD then be reviewed manually.
APP.4.6.A17 Avoidance of Client-Dependent Function Execution (S)
ABAP programs SHOULD NOT be programmed in a client-dependent manner such that they can only be executed by a specific client. If this is strictly necessary, it SHOULD be documented in detail. In addition, additional security measures SHOULD then be taken, such as a manual code review or quality assurance on the corresponding client.
APP.4.6.A18 Avoidance of Open SQL Injection Vulnerabilities (S)
Dynamic Open SQL SHOULD NOT be used. If database accesses with dynamic SQL conditions are necessary, NO user input SHOULD be passed in the respective query. If that is nevertheless the case, user input MUST be mandatorily validated (output encoding).
APP.4.6.A19 Protection Against Cross-Site Scripting (S)
Custom-developed HTML in Business Server Pages (BSP) applications or HTTP handlers SHOULD be avoided where possible.
APP.4.6.A20 No Access to Data of Another Client (S)
Automatic client separation SHOULD NOT be circumvented. Data of other clients SHOULD NOT be accessed using EXEC SQL or the Open SQL option CLIENT SPECIFIED.
APP.4.6.A21 Prohibition of Hidden ABAP Source Code (S)
The source code of a custom ABAP program SHOULD always be readable. Techniques that prevent this (obfuscation) SHOULD NOT be used.
Requirements for High Protection Needs
The following are exemplary proposals for requirements for this building block that go beyond the level of protection that corresponds to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the context of an individual risk analysis.
APP.4.6.A22 Use of ABAP Code Analysis Tools (H)
An ABAP code analysis tool SHOULD be used for automated review of ABAP code for security-relevant programming errors, functional and technical errors, and qualitative weaknesses.
Additional Information
Good to Know
In-depth information on ABAP programming can be found in the “Best Practice Guide: Development ABAP 2.0” of the German-speaking SAP User Group (DSAG).
Further information and best practices for secure ABAP programming can be found in the book “Sichere ABAP-Programmierung” (Secure ABAP Programming) by Wiegenstein, Schuhmacher, Schinzel, and Weidemann, published by SAP Press.