Security in business-oriented languages: ABAP

The ERP world: SAP and ABAP

Let’s talk about SAP and its common high-level business language, ABAP. The attack surface for SAP systems is wide, with web-facing options like ITS, BSP, Web Dynpro, Fiori… Dynamic ABAP code, remote function calls (RFC) and many other features open to new attack points.

In ABAP, OpenSQL is the common way for executing SQL code. OpenSQL is relatively safe against SQL injection, as input parameters to the SQL statement are considered data (not part of the SQL code, the ABAP runtime generates “parameterized SQL” for the target database, so each input is considered data). But for flexibility, dynamic SQL in OpenSQL is allowed (in FROM and WHERE clauses, in selected fields…). This opens the avenue for SQL injection:

Embedded native SQL (EXEC SQL … ENDEXEC) in the COBOL way is also allowed, but native SQL bypasses security features provided by OpenSQL (client separation, restrictive access to SQL commands), so it should not be used. And developers may use other alternatives, like ADBC (ABAP Database Connectivity) calls to classes like CL_SQL_STATEMENT or  DB_EXECUTE_SQL function module, or even kernel calls, which could be vulnerable to SQL injection. The effects of SQL injection exploits in SAP systems could be devastating. Just think about what could be done if the attacker could alter the REPOSRC table, where source code for standard and custom ABAP programs is stored…


Often, developers may use certain facilities that bypass proper data boundaries, sometimes provided by the SAP system. A good example is the SAP client separation: a single SAP instance could host business data from multiple organizations, also referred to as clients. The SAP database is designed to completely separase the business data of its clients. This mechanism is named “client separation”. Unfortunately, client separation could be bypassed by insecure ABAP coding practices, like the CLIENT SPECIFIED addition with OpenSQL:


Roles and authorizations are a central security topic in SAP environments. SAP provide functions and ABAP language statements (AUTHORIZE) to perform authorization checks. The problem here is that properly coding explicit SAP authorization checks in ABAP is not trivial. Not performing or performing incorrectly authorization checks may lead to information exposures and other consequences. The best authorization concept is rather useless if custom code does not check (correctly) the necessary authorizations.

One potential issue are the checks placed by developers on a particular SAP user, to avoid normal security checks for testing purposes. When the code is deployed in a production environment, such backdoor is open for potential attackers:

As an example of how authorization checks in ABAP could be misused due to the complexity of authorization checks in SAP, the following code show some flaws related to improper authorization:

Not checking authorizations may leak sensitive information. For example, to extract the anual salary for uses in the HR module, a developer may write:

Probably an explicit check for access to the PA0008 table should be added, to ensure that only allowed users may run the previous query: AUTHORITY-CHECK OBJECT 'S_TABU_NAM' ID 'TABLE' FIELD 'PA0008' ID 'ACTVT' FIELD '03' . See SAP table authorizations for full details.


SAP technology offer facilities for HTTP-mediated access. One simple example is BSP (Bussiness-server pages, the ABAP clone to JSP and ASP.Net server pages), which could be vulnerable to well-known web vulnerabilities, like the Open Redirect (CWE 601):

HTTP header manipulation/CRLF injection (CWE 113):

Or the dreaded Cross-Site Scripting (CWE 79):

Kiuwan and business-oriented languages

As part of the Software Analytics cloud platform (Kiuwan), specific security checks for business languages, like the ones mentioned, are included in the analytics model. This means that “legacy” software may be checked for vulnerabilities by the development team before delivery. The immediate benefits are:

  • Security issues are checked by static analysis, so teams may quickly check if potential flaws may pass security testing undetected.
  • Teams that may miss technical or information flaws may learn from the reported results of an analysis, to learn about how the flaw was produced in source code and how to remediate/prevent them in later maintenance changes.

The checks provided by Kiuwan (known as “rules”) could be classified in the following categories:

  • Injection issues (related to attacks like SQL injection, path traversal, code & resource injection, process control and, if the system allows it, cross-site scripting or other HTTP-related flaws).
  • System information leakage and privacy violations (when they could be characterized properly in static analysis).
  • Misuse of security controls provided by the platform (for example, authorization checks in ABAP).
  • Memory-related issues, like pointer arithmetic (when possible in the language) leading to potential buffer overflows, and dynamic storage leakage.
  • Poor error handling and unchecked return codes (for example, in calls to cryptographic APIs).
  • Hardcoded/commented credentials (usernames/passwords).
  • Problems with cryptographic APIs (algorithms deemed not strong enough, invalid initialization, predicatable pseudo-random generation…).
  • Banned dangerous constructs, like active debugging.
  • Reliability issues that compromise availability (for example, call parameter mismatch).

To end this post, let’s see some of these security checks available in Kiuwan. Do not hesitate to take a look at them!

Legacy Rules for Security