The purpose of this blog

This blog lists the checks that SAP NetWeaver AS, Add-On for Code Vulnerability Analysis provides.
The checks are made available with specific releases of SAP NetWeaver. For information as to which checks are available with which releases, please read note 1921820.

Background about Code Vulnerability Analyzer

The product “SAP NetWeaver Application Server add-on for code vulnerability analysis” is available for carrying out security checks. This is also called the code vulnerability analyzer (CVA). The CVA carries out a static analysis of the ABAP source code and reports possible security risks.
The CVA is a product in its own right and is subject to separate remuneration. If you enable the execution of the security checks, additional license costs are incurred.
You can allow the execution of system-wide security checks with the report RSLIN_SEC_LICENSE_SETUP. To carry out this step, you require authorization to make changes to global ATC check variants. Before activating the checks, make sure that you possess a valid license for the product. If in doubt, contact your sales representative at SAP.

Once the security checks are enabled, you can execute them in the ABAP Test Cockpit (ATC), the Code Inspector (SCI), and the extended program check. In the system, the security checks are sometimes called “Security Analyses in Extended Program Check (SLIN_SEC)”. We recommend that you execute the security checks via the ATC only. This is possible for automatic mass runs and in the ABAP development environment for individual objects.
SAP Note 1921820 describes the releases and Support Packages with which the code vulnerability analyzer is available. SAP Note 1949276 describes restrictions pertaining to the functional scope. The documentation for the report RSLIN_SEC_LICENSE_SETUP describes the individual security checks in more detail, among other things.

General points about security common to some of all of the checks below

Security problems can occur wherever external data (such as user input) is processed further without being checked.

Sometimes external data is used within a dynamic clause of an OPEN SQL statement. This could enable potential attackers to gain unauthorized access to the SAP database of the system by making unexpected input. This is known as an SQL injection.

Sometimes external data is used as a file name to open or delete files on the application server. This can give potential attackers access to the file system of the application server, so enabling them to access confidential information, modify file contents, and change the way the system behaves. This is known as directory traversal.

For information about a specific check, click on the appropriate link below:

Manipulation of dynamic Open SQL (Open SQL Injection)

Manipulation of SQL statements (Native SQL Injection)

Manipulation of dynamically generated ABAP code (ABAP Command Injections)

Manipulation in dynamic calls (Call Injections)

Injections of operating system commands

Potential unauthorized access to directories and files (Directory Traversal)

Insuffient authorization checks of user administration bypassed

Potential back doors

Possible attacks using Web technologies

Further checks

Here is a list by check number in ascending order:

Hard-coded user name – 0821

User name queries in ABAP indicate security problems. User-specific code often presents a back door for attackers.

Procedure

Check if the user name query could possibly indicate a back door. This can be the case, for example, if authorization checks are performed that depend on the user name. Remove these back doors.
Remove any user-dependent code that is not required to run the program.
Some applications cases require user-specific code. However, there is currently no method of detecting these code sections and excluding them from the checks.
The check runs in all places where the current user name (taken directly or indirectly from the system fields SY-UNAME or SYST-UNAME) is compared with a fixed value (taken directly or indirectly from a string literal). To do this, it views the logical condition of the predefined functions BOOLC or BOOLX and the following statements:

  1. IF, ELSEIF
  2. CASE, WHEN
  3. CHECK
  4. ASSERT

Some predefined user accounts delivered by SAP have special functions. Since the system must respond to these special user names in certain ways at particular times, comparisons made with these values are permitted and do not produce warnings. The following are some of the user names relevant here:

  • CSMREG
  • DDIC
  • EARLYWATCH
  • GOINGLIVE
  • SAP
  • SAP*
  • SAPCPIC
  • SAPSYS
  • SAPTERM
  • TMSADM

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Possible SQL injection (WHERE condition) – 1101

Potential manipulation of the dynamic where condition

The dynamic WHERE clause makes it possible for attackers to inject additional OR conditions that increase the volume of data selected in unexpected ways.

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

  1. ESCAPE_QUOTES
  2. ESCAPE_QUOTES_STR
  3. QUOTE
  4. QUOTE_STR
  5. CHECK_CHAR_LITERAL
  6. CHECK_STRING_LITERAL
  7. CHECK_INT_VALUE
  8. CHECK_VARIABLE_NAME
  9. CHECK_COLUMN_NAME
  10. CHECK_WHITELIST_STR
  11. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Ranges tables in a WHERE clause are not at risk of SQL injections. However, if technical reasons require ranges tables in WHERE conditions to be converted and then used in a dynamic WHERE clause, it is best to use the function module FREE_SELECTIONS_RANGE_2_WHERE. This module is identified as a secure data source; this is not usually the case in self-programmed conversions.

SAP discourages the use of literals with backquotes (`) in Open SQL statements, even though this is allowed by the syntax. Literals of this type look like string literals in ABAP, but do not have the same attributes. Literals in Open SQL statements are passed to the database, but any blanks at the end of the literals are ignored, which is not the case in ABAP string literals. This is why the use of literals with backquotes (`) can be confusing.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible directory traversal – 1104

Potential manipulation of the file name in the statement OPEN DATASET or DELETE DATASET

Procedure

Externally defined file names must be validated before a file is opened or deleted. This is done by the function module FILE_VALIDATE_NAME. This function module was made available with the Support Packages or correction instructions listed in SAP Note 1497003. The ABAP keyword documentation contains an example of file name validation.

Another option is to call the function module FILE_GET_NAME_AND_VALIDATE or FILE_GET_NAME. No unchecked data can be included in the parameter LOGICAL_FILENAME here. This means the automated check currently requires LOGICAL_FILENAME to be a constant. In the case of the function module FILE_GET_NAME, no unchecked data can be included in the parameters PARAMETER_1, PARAMETER_2, and PARAMETER_3 either.

The function module FILE_GET_NAME_AND_VALIDATE was made available with SAP Note 1957910.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

A local data flow analysis is performed.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Possible system command injection (addition FILTER) – 1106

Potential manipulation in the FILTER addition of the statement OPEN DATASET

The addition FILTER of the statement OPEN DATASET can be used to pass statements to the operating system. If this addition is filled from input data, potential attackers can inject further statements and modify the behavior of the application server in unexpected ways. These are known as system command injections.

Procedure

First check whether it is absolutely necessary to use the addition FILTER. If this is the case, an input check must be performed. The addition FILTER should not be used to send operating system commands.

If an operating system command call is absolutely necessary, however, the SAPXPG mechanism must be used. This offers increased security due to the following characteristics:

  • Abstraction from different operating systems
  • Predefined operating system commands
  • Stricter handling of parameters
  • Allows check modules (such as whitelists) to be defined
  • Predefined authorization check

New operating system commands must first be defined using transaction SM69. If possible, omit input values because these can also cause a security problem. The function module SXPG_CALL_SYSTEM can be used to make calls. See System Command Injections for more information.

In some cases, the class CL_ABAP_DYN_PRG can be used to perform a whitelist check. Here, the following methods are sufficient for the machine check in question (if the RETURNING parameter of the method in question is used in further processing):

  1. CHECK_WHITELIST_STR
  2. CHECK_WHITELIST_TAB

The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.

The escape methods of the class CL_ABAP_DYN_PRG are not suitable for operating system commands (or their parameters).

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

A local data flow analysis is performed.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Possible ABAP command injection – 1108

Potential injection of harmful code in the statements INSERT REPORT and GENERATE SUBROUTINE POOL

The statements INSERT REPORT and GENERATE SUBROUTINE POOL are used to generate ABAP programs dynamically, which can then be executed. If user input is entered directly in the source code of these generated programs, an attacker could potentially execute any of the operations in the system. These are known as ABAP command injections.

Procedure

Dynamic generation of ABAP code always carries a high level of risk to security. First, always check whether other dynamic programming methods can be used instead. If dynamic generations are absolutely necessary, all input data must be checked separately and appropriately.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

  1. ESCAPE_QUOTES
  2. ESCAPE_QUOTES_STR
  3. QUOTE
  4. QUOTE_STR
  5. CHECK_CHAR_LITERAL
  6. CHECK_STRING_LITERAL
  7. CHECK_INT_VALUE
  8. CHECK_VARIABLE_NAME
  9. CHECK_COLUMN_NAME
  10. CHECK_TABLE_OR_VIEW_NAME_STR
  11. CHECK_TABLE_OR_VIEW_NAME_TAB
  12. CHECK_TABLE_NAME_STR
  13. CHECK_TABLE_NAME_TAB
  14. CHECK_WHITELIST_STR
  15. CHECK_WHITELIST_TAB

Checks on the merged ABAP code passed to the statements INSERT REPORT or GENERATE SUBROUTINE POOL are not feasible.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible ABAP command injection via RFC Call – 1109

Potential injection of harmful code when the RFC-enabled function module RFC_ABAP_INSTALL_AND_RUN was called

Calling the RFC-enabled function module RFC_ABAP_INSTALL_AND_RUN allows dynamic ABAP programs (in remote systems) to be generated, which can then be executed. If user input is entered directly in the source code of these generated programs, an attacker could potentially execute any of the operations in the system. These are known as ABAP command injections.

Procedure

Dynamic generation of ABAP code always carries a high level of risk to security. First, always check whether other dynamic programming methods can be used instead. If dynamic generations are absolutely necessary, all input data must be checked separately and appropriately.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. ESCAPE_QUOTES_STR
        3. QUOTE
        4. QUOTE_STR
        5. CHECK_CHAR_LITERAL
        6. CHECK_STRING_LITERAL
        7. CHECK_INT_VALUE
        8. CHECK_VARIABLE_NAME
        9. CHECK_COLUMN_NAME
        10. CHECK_TABLE_OR_VIEW_NAME_STR
        11. CHECK_TABLE_OR_VIEW_NAME_TAB
        12. CHECK_TABLE_NAME_STR
        13. CHECK_TABLE_NAME_TAB
        14. CHECK_WHITELIST_STR
        15. CHECK_WHITELIST_TAB

Checks on the merged ABAP code passed to the function module RFC_ABAP_INSTALL_AND_RUN are not feasible.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (table Name when writing) 1110

Potentially important reports deleted from the ABAP repository

Security problems can occur wherever external data (such as user input) is processed further without being checked.
The statement DELETE REPORT or the function module RS_DELETE_PROGRAM can be used to delete programs from the ABAP repository. If the name of the deleted program is derived from user input, an attacker can potentially delete ABAP programs required by the application or the system and hence impair system functions.

Procedure

If at all possible, the names of programs deleted using DELETE REPORT or RS_DELETE_PROGRAM should not be derived from user input for security reasons. If this is absolutely necessary, the input data must be checked first accordingly.
The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

  1. 1. CHECK_WHITELIST_STR
  2. 2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
Performs a local data flow analysis.
If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (SET clause) 1112

Potential manipulation of the SET clause in the statement UPDATE

Potential attackers can use the dynamic SET clause to inject additional modifying expressions into the statement UPDATE, and so make unexpected database changes.

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. ESCAPE_QUOTES_STR
        3. QUOTE
        4. QUOTE_STR
        5. CHECK_CHAR_LITERAL
        6. CHECK_STRING_LITERAL
        7. CHECK_INT_VALUE
        8. CHECK_VARIABLE_NAME
        9. CHECK_COLUMN_NAME
        10. CHECK_WHITELIST_STR
        11. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

SAP discourages the use of literals with backquotes (`) in Open SQL statements, even though this is allowed by the syntax. Literals of this type look like string literals in ABAP, but do not have the same attributes. Literals in Open SQL statements are passed to the database, but any blanks at the end of the literals are ignored, which is not the case in ABAP string literals. This is why the use of literals with backquotes (`) can be confusing.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (column names) 1114

Potential read performed on invalid table columns

An attacker may be able to access forbidden columns by specifying the selected columns dynamically. Furthermore, in certain contexts (in INTO CORRESPONDING FIELDS) the attacker could attempt to manipulate the application by renaming columns (“COL1 AS COL2”).

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

If table columns exist that must not be read in the context in question, a whitelist check is a good idea (see below). In other case, this message is a false alarm.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (GROUP BY clause) 1116

Potential use of illegal columns in a dynamic GROUP BY clause

Potential attackers can use the dynamic GROUP BY clause to modify the selection in unexpected ways.

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_COLUMN_NAME
        2. CHECK_WHITELIST_STR
        3. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (HAVING clause) – 1117

Potential use of illegal columns in a dynamic HAVING clause

Potential attackers can use the dynamic HAVING clause to modify the selection in unexpected ways.

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. ESCAPE_QUOTES_STR
        3. QUOTE
        4. QUOTE_STR
        5. CHECK_CHAR_LITERAL
        6. CHECK_STRING_LITERAL
        7. CHECK_INT_VALUE
        8. CHECK_VARIABLE_NAME
        9. CHECK_COLUMN_NAME
        10. CHECK_WHITELIST_STR
        11. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

SAP discourages the use of literals with backquotes (`) in Open SQL statements, even though this is allowed by the syntax. Literals of this type look like string literals in ABAP, but do not have the same attributes. Literals in Open SQL statements are passed to the database, but any blanks at the end of the literals are ignored, which is not the case in ABAP string literals. This is why the use of literals with backquotes (`) can be confusing.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (table name when reading) – 1118

Potential read performed on an illegal database table in a SELECT statement

Potential attackers can specify tables dynamically and by doing this run operations on database tables other than those intended.

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_TABLE_OR_VIEW_NAME_STR
        2. CHECK_TABLE_OR_VIEW_NAME_TAB
        3. CHECK_TABLE_NAME_STR
        4. CHECK_TABLE_NAME_TAB
        5. CHECK_WHITELIST_STR
        6. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection (table name when writing) – 1120

Potential read performed on an illegal database table in a modifying OpenSQL statement

Potential attackers can specify tables dynamically and by doing this run operations on database tables other than those intended.

Procedure

First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_TABLE_OR_VIEW_NAME_STR
        2. CHECK_TABLE_OR_VIEW_NAME_TAB
        3. CHECK_TABLE_NAME_STR
        4. CHECK_TABLE_NAME_TAB
        5. CHECK_WHITELIST_STR
        6. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection via object services – 1122

Potential manipulation of a dynamic WHERE condition using the parameter I_FILTER of the object services method CREATE_QUERY

In the present case, external data is passed to the method CREATE_QUERY of an object services class. This class handles the data like a dynamic WHERE clause. This makes it possible for attackers to inject additional OR conditions that increase the volume of data selected in unexpected ways. This is known as an SQL injection.

Procedure

The input values for the parameter I_FILTER of the object services method CREATE_QUERY must be made subject to an input check.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. ESCAPE_QUOTES_STR
        3. QUOTE
        4. QUOTE_STR
        5. CHECK_CHAR_LITERAL
        6. CHECK_STRING_LITERAL
        7. CHECK_INT_VALUE
        8. CHECK_VARIABLE_NAME
        9. CHECK_COLUMN_NAME
        10. CHECK_WHITELIST_STR
        11. CHECK_WHITELIST_TAB

Furthermore, the function module FREE_SELECTIONS_RANGE_2_WHERE is also accepted as a suitable input check.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

SAP discourages the use of literals with backquotes (`) in Open SQL statements, even though this is allowed by the syntax. Literals of this type look like string literals in ABAP, but do not have the same attributes. Literals in Open SQL statements are passed to the database, but any blanks at the end of the literals are ignored, which is not the case in ABAP string literals. This is why the use of literals with backquotes (`) can be confusing.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible Directory Traversal via file utilities class – 1124

Potential manipulation of the file name in the method CREATE_UTF8_FILE_WITH_BOM of the class CL_ABAP_FILE_UTILITIES

Procedure

Externally defined file names must be validated before a file is opened or deleted. This is done by the function module FILE_VALIDATE_NAME. This function module was made available with the Support Packages or correction instructions listed in SAP Note 1497003. The ABAP keyword documentation contains an example of file name validation.

Another option is to call the function module FILE_GET_NAME_AND_VALIDATE or FILE_GET_NAME. No unchecked data can be included in the parameter LOGICAL_FILENAME here. This means the automated check currently requires LOGICAL_FILENAME to be a constant. In the case of the function module FILE_GET_NAME, no unchecked data can be included in the parameters PARAMETER_1, PARAMETER_2, and PARAMETER_3 either.

The function module FILE_GET_NAME_AND_VALIDATE was made available with SAP Note 1957910.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

A local data flow analysis is performed.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Potential directory traversal due to insecure parameters – 1126

Non-secure parameter of the function module FILE_GET_NAME used

In this case, the external data is passed to the non-secure parameters of function module FILE_GET_NAME.  If this data is part of the file name, users might be able to access data for which they have no authorization and read or even overwrite this data. This is also known as directory traversal.

Procedure

It is advisable to use the function module FILE_GET_NAME_AND_VALIDATE. This function module was made available with SAP Note 1957910.

If the function module FILE_GET_NAME still needs to be used:

In some cases, the class CL_ABAP_DYN_PRG can be used to perform a whitelist check. Here, the following methods are sufficient for the machine check in question (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

A local data flow analysis is performed. Here the parameters PARAMETER_1, PARAMETER_2, PARAMETER_3 of the function module FILE_GET_NAME are regarded as critical.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Possible SQL injection via ADBC (DDL) – 1128

Potential injection of harmful SQL statements or clauses in execution of DDL statements in ADBC

In the present case, external data is injected into an SQL statement that is passed for execution by the ADBC API of the database. This could enable potential attackers to gain unauthorized access to the SAP database of the system by making unexpected input. This is known as an SQL injection.

Unlike using Open SQL with dynamic clauses, ADBC is used to specify complete SQL statements. This increases the level of risk.

Procedure

First check whether it is necessary to use dynamic ADBC. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, consider a switch to dynamic Open SQL. This reduces the opportunities for attacks considerably.

If it is absolutely essential that you use ADBC, make sure that no user input is entered directly into the SQL statement. Use ? placeholders for dynamic components of the statement. The relevant ABAP data objects can then be connected to these placeholders by using the method SET_PARAM of class CL_SQL_STATEMENT.

In exceptional cases, it may still be necessary to create the SQL statement based on user entries. These entries must be thoroughly checked beforehand.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible SQL injection via ADBC (DML) – 1130

Potential injection of harmful SQL statements of clauses in execution of DML statements in ADBC

In the present case, external data is injected into an SQL statement that is passed for execution by the ADBC API of the database. This could enable potential attackers to gain unauthorized access to the SAP database of the system by making unexpected input. This is known as an SQL injection.

Unlike using Open SQL with dynamic clauses, ADBC is used to specify complete SQL statements. This increases the level of risk.

Procedure

First check whether it is necessary to use dynamic ADBC. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, consider a switch to dynamic Open SQL. This reduces the opportunities for attacks considerably.

If it is absolutely essential that you use ADBC, make sure that no user input is entered directly into the SQL statement. Use ? placeholders for dynamic components of the statement. The relevant ABAP data objects can then be connected to these placeholders by using the method SET_PARAM of class CL_SQL_STATEMENT.

In exceptional cases, it may still be necessary to create the SQL statement based on user entries. These entries must be thoroughly checked beforehand.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. QUOTE
        3. CHECK_CHAR_LITERAL
        4. CHECK_INT_VALUE
        5. CHECK_VARIABLE_NAME
        6. CHECK_COLUMN_NAME
        7. CHECK_TABLE_OR_VIEW_NAME_STR
        8. CHECK_TABLE_OR_VIEW_NAME_TAB
        9. CHECK_TABLE_NAME_STR
        10. CHECK_TABLE_NAME_TAB
        11. CHECK_WHITELIST_STR
        12. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Possible cross-site scripting – 1132

Potential risk of cross-site scripting

In the case in question, external data is used without encoding to generate a dynamic HTML page and then forwarded to the browser. This makes it possible for an attacker to send unwanted scripts to the browser of the victim (using unwanted input) and execute malicious code there. In this case, this is known as reflected cross-site scripting (XSS).

Procedure

The first check should verify whether modern Web frameworks can be used with automatic XSS protection, for example Web Dynpro or BSP with HTMLB extension, where encoding is activated globally (using the attribute forceEncode=”ENABLED” of the HTMLB:CONTENT tag). If this is not possible, the external data must be encoded before being used in the dynamic HTML page.

For BSP pages, global encoding can be set using the global page attribute forceEncode:

<%@page language=”abap” forceEncode=”html|url|javascript|css”%>

If necessary, global encoding can be overwritten by local encoding:

        • <%html=………%> – HTML encoding
        • <%url=……….%> – URL encoding for parameter names or parameter values of URLs
        • <%javascript=…%> – JavaScript encoding
        • <%css=……….%> – CSS encoding
        • <%raw=……….%> – No encoding

More information can be found in SAP Note 887168.

An encoding API should be used for generic Web applications. From Release SAP_BASIS 731, the built-in function ESCAPE:

        • out = escape(val = val format = cl_abap_format=>e_xss_ml)
        • out = escape(val = val format = cl_abap_format=>e_xss_js)
        • out = escape(val = val format = cl_abap_format=>e_xss_url)
        • out = escape(val = val format = cl_abap_format=>e_xss_css)

In lower releases, methods of the class CL_ABAP_DYN_PRG:

        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML
        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_JAVASCRIPT
        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_CSS
        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_URL

The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.

For more information, see “XSS Secure Programming Guide”. SAP Note 1714836.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Potential reflected cross-site scripting – 1134

Potential reflected cross-site scripting

In the case in question, external data from a HTTP request (such as URL parameters and HTML form fields) are used without encoding to generate a dynamic HTML page and then forwarded to the browser. This makes it possible for an attacker to send unwanted scripts to the browser of the victim (using unwanted input) and execute malicious code there. In this case, this is known as reflected cross-site scripting (XSS).

Procedure

The first check should verify whether modern Web frameworks can be used with automatic XSS protection, for example Web Dynpro or BSP with HTMLB extension, where encoding is activated globally (using the attribute forceEncode=”ENABLED” of the HTMLB:CONTENT tag). If this is not possible, the external data must be encoded before being used in the dynamic HTML page.

For BSP pages, global encoding can be set using the global page attribute forceEncode:

<%@page language=”abap” forceEncode=”html|url|javascript|css”%>

If necessary, global encoding can be overwritten by local encoding:

        • <%html=………%> – HTML encoding
        • <%url=……….%> – URL encoding for parameter names or parameter values of URLs
        • <%javascript=…%> – JavaScript encoding
        • <%css=……….%> – CSS encoding
        • <%raw=……….%> – No encoding

More information can be found in SAP Note 887168.

An encoding API should be used for generic Web applications. From Release SAP_BASIS 731, the built-in function ESCAPE:

        • out = escape(val = val format = cl_abap_format=>e_xss_ml)
        • out = escape(val = val format = cl_abap_format=>e_xss_js)
        • out = escape(val = val format = cl_abap_format=>e_xss_url)
        • out = escape(val = val format = cl_abap_format=>e_xss_css)

In lower releases, methods of the class CL_ABAP_DYN_PRG:

        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML
        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_JAVASCRIPT
        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_CSS
        • CL_ABAP_DYN_PRG=>ESCAPE_XSS_URL

The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.

For more information, see “XSS Secure Programming Guide”. SAP Note 1714836.

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

User-controlled dynamic CALL FUNCTION via RFC – 1140

Potential call of invalid function module using RFC

In the case in question, external data is used as the name of a function modules that is called using RFC. An attacker might be able to call forbidden function modules in other systems by entering unexpected data in this location. The problem is made worse because function parameters with incorrect names at runtime are ignored in this case and character-like parameters with incorrect lengths are truncated if necessary. This is also the case if ‘NONE’ was specified as DESTINATION.

Procedure

First check whether it is necessary to use dynamic procedure calls. Switching to static calls provides a full solution to the security problem presented here. If this is not possible, the input data must be checked accordingly before being used as function module names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Note

The message in questions is only produced for RFC calls, i.e. calls with the addition DESTINATION. In other dynamic function module calls, SLIN_SEC 1144 is produced if necessary.

User-controlled dynamic program unit call – 1141

Potential call of an illegal program using the statement SUBMIT

In the case in question, external data is used within a dynamic program call (meaning a dynamic call of a report or transaction). This enables potential attackers to call unexpected program units by making unexpected input, and thereby illegally modify the running of the program.

Procedure

First check whether it is necessary to use dynamic program calls. Switching to static calls provides a full solution to the security problem presented here. If this is not possible, the input data must be checked accordingly before being used as report names or transaction names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

User-controlled dynamic CALL TRANSACTION – 1142

Dynamic CALL TRANSACTION without whitelist check

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

A corresponding authorization check was found in the dynamic CALL TRANSACTION in question. This authorization check is usually enough to secure the dynamic CALL TRANSACTION statement in question. In special cases, it may be appropriate to have an additional whitelist check (see the following explanation).

In the case in question, external data is used within a dynamic program call (meaning a dynamic call of a report or transaction). This enables potential attackers to call unexpected program units by making unexpected input, and thereby illegally modify the running of the program.

Procedure

First check whether it is necessary to use dynamic program calls. Switching to static calls provides a full solution to the security problem presented here. If this is not possible, the input data must be checked accordingly before being used as report names or transaction names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

User-controlled dynamic LEAVE TO TRANSACTION – 1143

Potential call of an unwanted transaction using the statement LEAVE TO TRANSACTION

In the case in question, external data is used within a dynamic program call (meaning a dynamic call of a report or transaction). This enables potential attackers to call unexpected program units by making unexpected input, and thereby illegally modify the running of the program.

Procedure

First check whether it is necessary to use dynamic program calls. Switching to static calls provides a full solution to the security problem presented here. If this is not possible, the input data must be checked accordingly before being used as report names or transaction names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Dynamic function module call controllable from UI or via RFC – 1144

UI-driven or RFC-driven dynamic call of a function module

Here, the name of a called function module can be controlled using either the user interface or a parameter of an RFC-enabled function module.

An attacker might be able to call forbidden function modules by entering unexpected data in this location.

Procedure

First check whether it is necessary to use dynamic function module calls. Switching to static calls provides a full solution to the security problem presented here. If this is not possible, the input data must be checked accordingly before being used as function module names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Dynamic function module calls are frequent, which means that only those calls are registered here for which some or all of the function module name can be controlled meaningfully using the user interface or RFC. To do this, a local data flow analysis is performed.

If a source code position is flagged and does not present a security problem and an input check (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Note:

        • This message (SLIN_SEC 1144) is not raised for dynamic function module calls that represent an RFC call. In dynamic RFC calls like this, SLIN_SEC 1140 is produced if necessary. For this reason, the checks SLIN_SEC 1140 and 1144
        • must always be performed together (neither of the checks should be suppressed using its priority) or
        • must always be suppressed together using their priorities.
        • A local data flow analysis is performed, which means that exactly those occurrences are registered in which the function module name can be controlled using the user interface of the wrapper program or in which dynamic calls within a function group can be controlled using the parameter of an RFC-enabled function module of this function group.

Static CALL TRANSACTION without check of authorization object from SE93 – 114A

Static CALL TRANSACTION without check on authorization from the transaction editor

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

Here, a check on the authorization object S_TCODE was found. The additional check was specified in the transaction editor, but no check on this authorization was found in the code. This could present a security risk.

Procedure

If the authorization check is missing by accident, it can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization object S_TCODE. It may be a good idea to remove the explicit AUTHORITY-CHECK on S_TCODE.

If the check on the authorization object from the transaction editor in CALL TRANSACTION was skipped intentionally, the addition WITHOUT AUTHORITY-CHECK in CALL TRANSACTION can be used from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption.

For each CALL TRANSACTION, a search is made for the AUTHORITY-CHECKs or a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a nesting depth of five. If an AUTHORITY-CHECK on the authorization object S_TCODE is found, but no AUTHORITY-CHECK that matches the entry from the transaction editor, the message is displayed.

Static CALL TRANSACTION without check of authorization object S TCODE – 114B

Static CALL TRANSACTION without check on authorization object S_TCODE.

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

Here, a check on the authorization object from the transaction editor (SE93) was found. The code, however, did not contain a check on the authorization object S_TCODE for the called transaction. This could present a security risk.

Procedure

If the authorization check is missing by accident, it can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization from the transaction editor (SE93) and the authorization object S_TCODE. It may be a good idea to remove the explicit AUTHORITY-CHECK on the authorization from the transaction editor (SE93).

If the check on the authorization object S_TCODE in CALL TRANSACTION was skipped intentionally, the addition WITHOUT AUTHORITY-CHECK in CALL TRANSACTION can be used from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption.

For each CALL TRANSACTION, a search is made for the AUTHORITY-CHECKs or a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a nesting depth of five. If an AUTHORITY-CHECK on the authorization from the transaction editor (SE93) is found, but no AUTHORITY-CHECK on S_TCODE, the message is displayed.

Static CALL TRANSACTION without authorization check – 114C

Static CALL TRANSACTION without authorization check

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

Here, none of the authorization checks above were found in the code. This could present a security risk.

Procedure

If the authorization checks are missing by accident, they can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization object S_TCODE and the authorization from the transaction editor (SE93). However, you should note that table TCDCOUPLES is taken into account for function module AUTHORITY_CHECK_TCODE.

In a few situations, it is intentional that no authorizations are checked in CALL TRANSACTION (or only the authorization for the authorization S_TCODE). In these cases, the addition WITHOUT AUTHORITY-CHECK can be used in CALL TRANSACTION from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption. In dynamic CALL TRANSACTIONSs, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a whitelist check).

SAP recommends that the entries in table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.

For each CALL TRANSACTION, a search is made for the AUTHORITY-CHECKs or a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a restricted nesting depth. The message is displayed if none of the authorization checks above are found.

Static CALL TRANSACTION without authorization check (restricted function) – 114D

Static CALL TRANSACTION without authorization check in the case of restricted functions

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

Here, none of the authorization checks above were found in the code. This could present a security risk. The security risk becomes slightly less severe because a restriction to a specific context (AND SKIP FIRST SCREEN or USING bdc_tab) was found in the statement CALL TRANSACTION .

Procedure

If the authorization checks are missing by accident, they can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization object S_TCODE and the authorization from the transaction editor (SE93). However, you should note that table TCDCOUPLES is taken into account for function module AUTHORITY_CHECK_TCODE.

In a few situations, it is intentional that no authorizations are checked in CALL TRANSACTION (or only the authorization for the authorization S_TCODE). In these cases, the addition WITHOUT AUTHORITY-CHECK can be used in CALL TRANSACTION from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption. In dynamic CALL TRANSACTIONSs, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a whitelist check).

SAP recommends that the entries in table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.

For each CALL TRANSACTION, a search is made for the AUTHORITY-CHECKs or a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a restricted nesting depth. The message is displayed if none of the authorization checks above are found.

Dynamic CALL TRANSACTION without authorization check – 114E

Dynamic CALL TRANSACTION without authorization check

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

In the dynamic CALL TRANSACTION in question, none of the authorization checks above were found in the code. This could present a security risk.

A whitelist check restricts the set of potential transactions called, which means that the security risk is already reduced. Depending on the context, this restriction may be enough.

Procedure

If the authorization checks are missing by accident, they can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization object S_TCODE and the authorization from the transaction editor (SE93). However, you should note that table TCDCOUPLES is taken into account for function module AUTHORITY_CHECK_TCODE.

In a few situations, it is intentional that no authorizations are checked in CALL TRANSACTION (or only the authorization for the authorization S_TCODE). In these cases, the addition WITHOUT AUTHORITY-CHECK can be used in CALL TRANSACTION from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption. In dynamic CALL TRANSACTIONSs, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a whitelist check).

SAP recommends that the entries in table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.

For each dynamic CALL TRANSACTION, a search is made for the a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a restricted nesting depth. The message is displayed if none of the authorization checks above are found.

Dynamic CALL TRANSACTION with dataflow and without authorization check – 114F

Dynamic CALL TRANSACTION without authorization check and without whitelist check

In the case in question, external data is used within a dynamic transaction call. This enables potential attackers to call unexpected transactions by making unexpected input, and thereby illegally modify the running of the program.

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

In this dynamic CALL TRANSACTION, the potential influence of the user input on the called transaction was identified and, additionally, none of the authorization checks mentioned above were found in the source code. This could present a security risk.

Procedure

Both the authorization check aspect and the aspect of dynamics in the name of the called transaction must be considered. In most situations, an authorization check is the best choice for removing the security problem.

Authorization check

If the authorization checks are missing by accident, they can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization object S_TCODE and the authorization from the transaction editor (SE93). However, you should note that table TCDCOUPLES is taken into account for function module AUTHORITY_CHECK_TCODE.

In a few situations, it is intentional that no authorizations are checked in CALL TRANSACTION (or only the authorization for the authorization S_TCODE). In these cases, the addition WITHOUT AUTHORITY-CHECK can be used in CALL TRANSACTION from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption. In dynamic CALL TRANSACTIONSs, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a whitelist check).

SAP recommends that the entries in table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.

Dynamics in the name of the called transaction

First check whether it is necessary to use dynamic transaction calls. Switching to static calls provides a solution to the security problem presented here at least. If this is not possible, the input data must be checked accordingly before being used as transaction names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

If an authorization check is not predefined, an error message stating that the authorization check is missing might be raised the next time the program is checked.

A local data flow analysis is performed.

For each dynamic CALL TRANSACTION, a search is made for the a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a restricted nesting depth. The message is displayed if none of the authorization checks above are found.

Dynamic CALL TRANSACTION with data flow, authorization check of S TCODE – 114G

Dynamic CALL TRANSACTION with potentially incomplete authorization check

In the case in question, external data is used within a dynamic transaction call. This enables potential attackers to call unexpected transactions by making unexpected input, and thereby illegally modify the running of the program.

When a transaction is started from the user interface or by executing the ABAP command LEAVE TO TRANSACTION, an authorization check is performed automatically. The check is always made using the authorization object S_TCODE . In the transaction code editor (transaction SE93), developers can specify an authorization object with authorization values. If an entry of this type is found, the authorization specified there is checked.

These authorization checks are not usually made  when the ABAP command CALL TRANSACTION is executed. The developer of the program in question must decide whether the transaction start authorization is checked.

In this dynamic CALL TRANSACTION, the potential influence of the user input on the called transaction was identified and, additionally, only one authorization check on the authorization object S_TCODE was found in the source code. The authorization check might be incomplete, since the system analysis cannot decide whether a check was made on the authorization from the transaction editor (transaction SE93). This could present a security risk.

Procedure

Both the authorization check aspect and the aspect of dynamics in the name of the called transaction must be considered. In most situations, an authorization check is the best choice for removing the security problem.

Authorization check

If the authorization checks are missing by accident, they can implemented in full by simply calling the function module AUTHORITY_CHECK_TCODE . From SAP_BASIS 7.40 SP 02, the addition WITH AUTHORITY-CHECK in CALL TRANSACTION can also be used to do this. It works in the same way as the function module call. Both methods check the authorization object S_TCODE and the authorization from the transaction editor (SE93). However, you should note that table TCDCOUPLES is taken into account for function module AUTHORITY_CHECK_TCODE.

In a few situations, it is intentional that no authorizations are checked in CALL TRANSACTION (or only the authorization for the authorization S_TCODE). In these cases, the addition WITHOUT AUTHORITY-CHECK can be used in CALL TRANSACTION from SAP_BASIS 7.40 SP 02. In systems with older releases, the message must be suppressed using an exemption. In dynamic CALL TRANSACTIONSs, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a whitelist check).

SAP recommends that the entries in table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.

Dynamics in the name of the called transaction

First check whether it is necessary to use dynamic transaction calls. Switching to static calls provides a solution to the security problem presented here. If this is not possible, the input data must be checked accordingly before being used as transaction names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

A local data flow analysis is performed.

For each dynamic CALL TRANSACTION, a search is made for the a suitable call of the function module AUTHORITY_CHECK_TCODE within the same procedure (event, method, function, form routine). In called procedures, a search is also performed for these authorization checks up to a restricted nesting depth. The message is displayed if none of the authorization checks above are found.

Usage of an obsolete escaping method – 1150

Obsolete escape method used

The ESCAPE methods of classes CL_HTTP_UTILITY, CL_HTTP_SERVER and CL_HTTP_CLIENT are obsolete and do not fulfill the current OWASP recommendations. They have been replaced by the predefined function ESCAPE( ).

Procedure

Calls of the obsolete escape methods must be replaced by calls of the predefined function ESCAPE( ), appropriate for the context in question. Valid formats are the values E_XSS_* from the class CL_ABAP_FORMAT. More information is available in the ABAP keyword documentation.

The specified formats are not available for the predefined function ESCAPE( ) in releases older than SAP_BASIS 731. Instead, you need to use the ESCAPE_XSS_* methods from class CL_ABAP_DYN_PRG. The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.

All calls of the obsolete methods are reported. This relates to the following methods:

        • CL_HTTP_UTILITY=>ESCAPE_JAVASCRIPT
        • CL_HTTP_UTILITY=>ESCAPE_HTML
        • CL_HTTP_UTILITY=>ESCAPE_URL
        • CL_HTTP_UTILITY=>ESCAPE_WML
        • CL_HTTP_UTILITY=>ESCAPE_XML_CHAR_DATA
        • CL_HTTP_UTILITY=>ESCAPE_XML_ATTR_VALUE
        • CL_HTTP_SERVER=>ESCAPE_HTML
        • CL_HTTP_SERVER=>ESCAPE_URL
        • CL_HTTP_CLIENT=>ESCAPE_HTML
        • CL_HTTP_CLIENT=>ESCAPE_URL

forceEncode=”enabled” not specified for htmlb:content 1151

On BSP pages that use htmlb, the values of the attributes of the htmlb tags are encoded only if the attribute forceEncode in htmlb:content has the value ‘enabled’. This is the only way to ensure that the encoding matches the context in which an attribute value is used in the finished HTML document.

Procedure

The attribute forceEncode of the htmlb tag htmlb:content is set to the value ‘enabled’.

For more information, see “XSS Secure Programming Guide”. SAP Note 1714836.

If the position in question does not have any security problems and there is no point in modifying the BSP page, an exemption should be requested in ATC.

In tag htmlb:content an obsolete design is specified or none at all – 1152

Obsolete design or no design specified for htmlb:content

Message number 1152

The designs CLASSIC and DESIGN2002 are no longer supported. This means that any XSS weaknesses in the associated BSP extensions htmlb, xhtmlb, and so on are no longer corrected.

Only the designs DESIGNS2003 and DESIGN2008 (and any later designs) encode all attributes in full and are secure with respect to cross site scripting (XSS).

Procedure

Obsolete designs can no longer be used. A design must be specified explicitly, since otherwise the obsolete design CLASSIC is used.

For more information, see “XSS Secure Programming Guide”. SAP Note 1714836.

AUTHORITY-CHECK without processing of sy-subrc – 1160

SY-SUBRC not evaluated after the statement AUTHORITY-CHECK

After the statement AUTHORITY-CHECK, sy-subrc needs to be read. If sy-subrc is not equal to 0, the authorization check was not successful.

The check confirms whether a read is performed on sy-subrc directly after AUTHORITY-CHECK. Statements such as ENDIF, simple assignments (that do not modify sy-subrc), or comments are permitted before reads. Some declarative statements, such as DATA, are also valid. Many ABAP statements (such as REFRESH) set sy-subrc and are not allowed. If there is an empty IF/ENDIF block after AUTHORITY-CHECK, a problem is detected.

Procedure

Insert a sy-subrc query with a valid response (for example, cancel).

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Call of a security-relevant method without handling the return value – 1161

Return value (for example, SY-SUBRC) not evaluated after a security-relevant method was called

It is necessary to evaluate the return value (for example, SY-SUBRC) after a security-relevant method such as CL_SACF=>AUTH_CHECK_SPEC( ) has been called.

From the perspective of this check, the following methods are security-relevant:

        • CL_SACF=>AUTH_CHECK_SPEC( )
        • CL_SACF=>AUTH_CHECK_SPEC_USER( )

Further procedures can be registered as security-relevant using the BAdI SLIN_BADI_SEC_PROCEDURES. All registered security-relevant function modules and methods can be displayed using the report RSLIN_SEC_DISPLAY_SECREL_PROC.

This check checks whether the return value (for example, SY-SUBRC) is read immediately after the procedure call. Statements such as ENDIF, simple assignments (that do not modify the return value), or comments are permitted before reads. Some declarative statements, such as DATA, are also valid. If there is an empty IF/ENDIF block after the method call, a problem is registered.

Procedure

Insert an evaluation of the return value (for example, SY-SUBRC) with an appropriate response (for example, error message or cancel).

If the message is caused by an inconsistent BAdI implementation, contact the person responsible for the BAdI implementation classes specified in the message details.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Call of a security-relevant function without processing sy-subrc – 1165

After a security-relevant function module such as AUTHORITY_CHECK_TCODE or AUTHORITY_CHECK is called, the return value (for example, SY-SUBRC) must be evaluated.

From the perspective of this check, the following function modules are security-relevant:

        • AUTHORITY_CHECK
        • AUTHORITY_CHECK_TCODE
        • SU_RAUTH_CHECK_FOR_USER
        • VIEW_AUTHORITY_CHECK
        • FILE_VALIDATE_NAME
        • AUTHORITY_CHECK_DATASET
        • AUTHORITY_CHECK_RFC

Further procedures can be registered as security-relevant using the BAdI SLIN_BADI_SEC_PROCEDURES. All registered security-relevant function modules and methods can be displayed using the report RSLIN_SEC_DISPLAY_SECREL_PROC.

This check checks whether the return value (for example, SY-SUBRC) is read immediately after the procedure call. Statements such as ENDIF, simple assignments (that do not modify the return value), or comments are permitted before reads. Some declarative statements, such as DATA, are also valid. If there is an empty IF/ENDIF block after the method call, a problem is registered.

Procedure

Insert an evaluation of the return value (for example, SY-SUBRC) with an appropriate response (for example, error message or cancel).

If the message is caused by an inconsistent BAdI implementation, contact the person responsible for the BAdI implementation classes specified in the message details.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Call of system function CALL “SYSTEM” – 1170

Statement CALL “SYSTEM” used

The system function call CALL ‘SYSTEM’ can be used to execute operating system commands. However, calling operating system commands can be a potential security problem. This is a particular risk in cases where end users can modify or manipulate the parameters of an operating system command.

Usually all system function calls (CALL cfunc) are only allowed to be used in system programs and are not allowed to be used in application programs.

Procedure

Operating system commands should not be called from ABAP.

If an operating system command call is absolutely necessary, however, the SAPXPG mechanism must be used. This offers increased security due to the following characteristics:

        • Abstraction from different operating systems
        • Predefined operating system commands
        • Stricter handling of parameters
        • Allows check modules (such as whitelists) to be defined
        • Predefined authorization check

New operating system commands must first be defined using transaction SM69. If possible, omit input values because these can also cause a security problem. The function module SXPG_CALL_SYSTEM can be used to make calls. See System Command Injections for more information.

All uses of the system function call CALL ‘SYSTEM’ are registered.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

System function call with potential user input on FIELD – 1171

C function call with names as potential user input

The ABAP command CALL cfunc can be used to execute specific C functions in the kernel. However, calling C functions can be a potential security problem.

Potential attackers can call unwanted kernel functions by making unexpected input, and thereby illegally modify the running of the program.

Procedure

If possible, avoid calling C functions from ABAP. You can do this by using official APIs (such as function modules and methods).

If this is not possible, check whether it is really necessary to use dynamic calls of C functions. One solution is to switch to using static calls. If this is not possible either, the input data must be checked accordingly before being used as C function names.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. CHECK_WHITELIST_STR
        2. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

If user input is incorporated in the names cfunc, the CALL statement is reported. A local data flow analysis is performed to do this.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

AUTHORITY-CHECK for specified User – 1180

AUTHORITY-CHECK with explicit user name

The statement AUTHORITY-CHECK is used together with the addition FOR USER to check the authorization of the user specified by FOR USER (and not for the logged on user). This is often a very sensible requirement.

Example: Data needs to be processed using a specific user in a background job. Before the job is scheduled, AUTHORITY-CHECK FOR USER checks whether the user has the required authorization. In the background job itself, however, the current user should check the authorization again.

If the user name specified using FOR USER has an external source (such as GUI input, an RFC interface, or a file), an attack can manipulate the user name in certain circumstances. In this way, this variant of the statement AUTHORITY-CHECK can be misused to gain additional authorizations that the logged on user is not allowed to have. The addition FOR USER can be used to specify a predefined/delivered user (such as DDDIC or SAP*), which can then be used in certain circumstances to gain administrative rights.

The function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER offer similar options and can also be viewed as a potential source of hazards.

Procedure

Try to avoid using the addition FOR USER with the statement AUTHORITY-CHECK . The addition FOR USER sy-uname or FOR USER syst-uname in particular is usually not required. Instead, use the statement AUTHORITY-CHECK without the addition FOR USER. The same applies to the function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER.

If an authorization check needs to be run for a user other than the logged on user, it is important to ensure that the user name specified for the addition FOR USER cannot be manipulated externally (by making entries on the user interface, for example). Checks against a whitelist can be a good way of verifying user names entered from outside. Request an exemption for cases where the addition FOR USER is essential and not just useful.

In the example above (authorization check before scheduling a background job for the user name to be used to run the job), it is important that you perform an authorization check yourself in the background job.

If you want to query the authorization for the user currently logged on locally in RFC calls of the function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER, you should obtain the user name using a call of the method cl_abap_syst=>get_user_name( ) and pass it to the function module. This method, however, still produces a security message (such as “Querying an authorization for a user presents a security risk.”). Request an exemption in this case.

All uses of the statement AUTHORITY-CHECK with the addition FOR USER are reported. Here, the source of the user name is not checked. Any whitelist checks are ignored.

The local use of the function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER is handled in a similar way, since they offer mainly the same functions.

AUTHORITY-CHECK for SY-UNAME – 1181

AUTHORITY-CHECK with addition FOR USER sy-uname

The statement AUTHORITY-CHECK is used together with the addition FOR USER to check the authorization of the user specified by FOR USER (and not for the logged on user). This is often a very sensible requirement.

It does not make any sense, however, to specify FOR USER sy-uname or FOR USER syst-uname.

If the function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER are called, the situation is different. Local calls of these function modules are not a good idea, since the statement AUTHORITY-CHECK is far quicker and produces the same result. In RFC calls of these functions, it is often a requirement to check the authorization for the same user ID as the logged on user in the local system. Here it is advisable to obtain the name of the user logged on locally using the method cl_abap_syst=>get_user_name( ).

Procedure

Do not use the additions FOR USER sy-uname or FOR USER syst-uname in the statement AUTHORITY-CHECK.

Replace the local calls of the function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER by the statement AUTHORITY-CHECK without the clause FOR USER.

If you want to pass the user name of the user logged on locally for RFC calls of these function modules, use the method cl_abap_syst=>get_user_name( ) to obtain the user name. However, you should note that this user name might be assigned to a different person in the called system.

The additions FOR USER sy-uname and FOR USER syst-uname are registered in the statement AUTHORITY-CHECK.

Local calls of the function modules AUTHORITY_CHECK and SU_RAUTH_CHECK_FOR_USER produce a message when the user name sy-uname or syst-uname is specified.

The dynamic WHERE condition allows a potential code injection – 1190

Potential manipulation of the dynamic WHERE condition in an internal table

The dynamic WHERE clause makes it possible for attackers to inject additional conditions, joined using OR or AND, that modify the volume of data selected in unexpected ways. These conditions can also contain functional ABAP method calls.

Procedure

First check whether it is necessary to use the dynamic WHERE clause. Switching to a static WHERE clause provides a full solution to the security problem.  If this is not possible, the input data must be checked appropriately before being used in the dynamic clause.

The documentation of the class CL_ABAP_DYN_PRG explains how input data needs to be handled when constructing a dynamic WHERE clause.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. ESCAPE_QUOTES_STR
        3. QUOTE
        4. QUOTE_STR
        5. CHECK_CHAR_LITERAL
        6. CHECK_STRING_LITERAL
        7. CHECK_INT_VALUE
        8. CHECK_VARIABLE_NAME
        9. CHECK_COLUMN_NAME
        10. CHECK_WHITELIST_STR
        11. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Potentially missing authorization check in a report– 11A1

Authorization checks should be used to secure reports against being called by unauthorized users.

Procedure

Check whether an authorization check exists for this report and, if necessary, add a check at the start of the report. If the report is already being used or has been delivered, a switchable authorization check should be integrated using the method call CL_SACF=>AUTH_CHECK_SPEC( ).

The report code is scanned for specific authorization checks (see below), including its form routines, dynpro modules, function calls, and method calls.

The following authorization checks are found:

  • ABAP command: AUTHORITY-CHECK (without the addition FOR USER)
  • Function call: CALL FUNCTION ‘AUTHORITY_CHECK’
  • Function call: CALL FUNCTION ‘AUTHORITY_CHECK_TCODE’
  • Function call: CALL FUNCTION ‘AUTH_CHECK_TCODE’
  • Method call: CALL METHOD CL_SACF=>AUTH_CHECK_SPEC

Authorization checks against authorization object B_BUP_PCPT are ignored.

The system also searches for potentially dangerous statements. These include database access and file access in particular. If a statement like this is found before an authorization check, a message is displayed.

It is also possible to assign an authorization group to the report, in which case an authorization check does not need to be integrated and no message is displayed (if the group is valid). The authorization group can be entered in the properties of the report.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Potentially missing authorization check in an RFC function module – 11A2

Authorization checks should be used to secure RFC function modules against being called by unauthorized users.

Procedure

Check whether an authorization check exists for this RFC function module and, if necessary, add a check at the start of the RFC function module. If the RFC function module is already being used or has been delivered, a switchable authorization check should be integrated using the method call CL_SACF=>AUTH_CHECK_SPEC( ).

The RFC function module code is scanned for specific authorization checks (see below), including its form routines, dynpro modules, function calls, and method calls.

The following authorization checks are found:

  • ABAP command: AUTHORITY-CHECK
  • Function call: CALL FUNCTION ‘AUTHORITY_CHECK’
  • Function call: CALL FUNCTION ‘AUTHORITY_CHECK_TCODE’
  • Function call: CALL FUNCTION ‘AUTH_CHECK_TCODE’
  • Method call: CALL METHOD CL_SACF=>AUTH_CHECK_SPEC

Authorization checks against authorization object B_BUP_PCPT are ignored.

The system also searches for potentially dangerous statements. These include database access and file access in particular. If a statement like this is found before an authorization check, a message is displayed.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Use of command COMMUNICATION – 11C1

Statement COMMUNICATION used

The statement COMMUNICATION is based on a non-secure communication protocol. Neither this protocol nor the statement COMMUNICATION should be used any longer.

Procedure

Use a different communication protocol, such as RFC, instead of the existing code.

All places where the statement COMMUNICATION is used are detected.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Potential SQL injection – 11D1

Potential injection of malicious SQL statements or clauses

In the case in question, external data is injected into an SQL statement that is passed for execution by the database. This could enable potential attackers to gain unauthorized access to the SAP database of the system by making unexpected input. This is known as an SQL injection.

Procedure

It is important that user input is not injected directly into the SQL statement.  If it is necessary to create the SQL statement based on user input regardless of this, this input must be thoroughly checked beforehand.

The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):

        1. ESCAPE_QUOTES
        2. QUOTE
        3. CHECK_CHAR_LITERAL
        4. CHECK_INT_VALUE
        5. CHECK_VARIABLE_NAME
        6. CHECK_COLUMN_NAME
        7. CHECK_TABLE_OR_VIEW_NAME_STR
        8. CHECK_TABLE_OR_VIEW_NAME_TAB
        9. CHECK_TABLE_NAME_STR
        10. CHECK_TABLE_NAME_TAB
        11. CHECK_WHITELIST_STR
        12. CHECK_WHITELIST_TAB

Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.

Performs a local data flow analysis.

If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.

Missing content check during HTTP upload -11F1

Method IF_HTTP_REQUEST~GET_DATA( ) was called without parameter VSCAN_SCAN_ALWAYS.

In certain cases, this could lead to Cross-Site-Scripting (XSS) via file upload (MIME sniffing). For more information, see the “SAP NetWeaver Security Guide” (“Network Services” -> “Preventing Cross-Site Scripting From Uploads”).

Procedure

Method IF_HTTP_REQUEST~GET_DATA( ) should be called with parameter VSCAN_SCAN_ALWAYS set (see Note 1883929).

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Calls of methods IF_HTTP_REQUEST~GET_DATA( ) and IF_HTTP_ENTITY~GET_DATA( ) without parameter VSCAN_SCAN_ALWAYS are reported.

See Also

“XSS Secure Programming Guide”. SAP Note 1714836.

SAP Note 1693981.

Direct read access to critical database tables – 11G0

Read on sensitive database tables

A sensitive database table was read in a customer system.

These can be SAP tables (if not in the list of database tables registered as harmless).

These can also be all database tables registered as sensitive tables in the list.

Database tables can be registered as sensitive or harmless using the BAdI SLIN_BADI_DBTAB_ACCESS (see the documentation).

Procedure

These database tables must not be accessed.

Write access to sensitive database tables – 11G1

Write on sensitive database tables

A write was performed on a sensitive database table in a customer system.

These can be SAP tables (if not in the list of database tables registered as harmless).

These can also be all database tables registered as sensitive tables in the list.

Database tables can be registered as sensitive or harmless using the BAdI SLIN_BADI_DBTAB_ACCESS (see the documentation).

Procedure

These database tables must not be accessed.

Hard-coded password – 11K1

A method or function was called with a hard coded password. This is a possible indication, for example, that a user or an RFC destination exists in the system with logon data from the source code.

Example

CALL FUNCTION ‘BAPI_USER_CREATE1’   EXPORTING     USERNAME  = ‘USER1’     PASSWORD  = ‘Abcd1234’     …

Procedure

Verify that the hard coded password is necessary and, if possible, stop using the hard coded value.

The check does not return a message in the following cases:

        • The password comes from user input.
        • The password is from the database.
        • The password was generated, for example using the function SUSR_GENERATE_PASSWORD. Some APIs, such as BAPI_USER_CREATE1, return a generated password when a user is created.

All method calls and function calls are logged in which a password-relevant IMPORTING CHANGING parameter has a hard coded value. A parameter is password-relevant if it follows a particular naming convention.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Open URL redirect – 11P1

Potential Unvalidated URL Redirect

In the case in question, external data from an HTTP request (such as URL parameters or HTML form fields) is used as a source for URL redirect, or the data is used to create an HTTP Header with dynamic field names. This makes it possible for attackers to redirect victims to other websites. These cases are known as unvalidated URL redirects.

Example

It is important to differentiate between the following two cases:

1. URL redirect API call

DATA RESPONSE TYPE REF TO IF_HTTP_RESPONSE.          …          RESPONSE->REDIRECT( LV_URL ).          RESPONSE->SET_HEADER_FIELD( NAME = ‘LOCATION’ VALUE = LV_URL ).          RESPONSE->SET_HEADER_FIELD( NAME = ‘REFRESH’ VALUE = LV_URL ).

2. Call of IF_HTTP_RESPONSE~SET_HEADER_FIELDS or SET_HEADER_FIELD with dynamic HTTP Header field names

RESPONSE->SET_HEADER_FIELD( NAME = LV_NAME VALUE = LV_URL ).          RESPONSE->SET_HEADER_FIELDS( FIELDS = LT_HTTPNVP_TAB ).

Procedure

URL redirect API call

It is first necessary to check whether URL redirects by URL destination can be avoided by user input. If this is not possible, the input data should be checked via whitelist before being used in HTTP redirects.

In this case, the automated check views the whitelist method CL_HTTP_UTILITY=>CHECK_HTTP_WHITELIST, with a corresponding ENTRY_TYPE (for example, 99 – Generic Redirect), as sufficient, if the RETURNING parameter of the method is used for further processing.

This method is provided in support packages or correction instructions (see SAP Note 2189853).

SET_HEADER_FIELDS or SET_HEADER_FIELD with dynamic HTTP Header field names

In this case, the automatic check cannot estimate whether the call with dynamic field names will result in a URL redirect. Therefore, you should check whether SET_HEADER_FIELDS or SET_HEADER_FIELD with dynamic fields can be avoided. If this is not possible, you should apply for an exemption in ATC.

A local data flow analysis is performed.

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

The BSP application is not protected against XSRF – 11RF

The BSP application is not protected against cross-site request forgeries (XSRF).

Procedure

Select the “XSRF protection” checkbox for the BSP application.

If the place in question is not a security risk (Public BSP, has its own XSRF protection), apply for an exemption in ATC.

Hard-coded host name – 11S1

Hard-coded host name, possibly from forgotten test code or an indication of a back door

Host name queries in ABAP indicate security problems. Host-specific code often presents a back door for attackers.

Procedure

Check whether the host name query could possibly indicate a back door. Remove these back doors.

Remove any host-specific code that is not required to run the program.

Some applications cases require host-specific code. However, there is currently no method of detecting these code sections and excluding them from the checks.

Check whether suitable customizing or a suitable API could help to apply distinct behavior to individual hosts in these cases.

All occurrences are reported in which the current host name from the system fields SY-HOST and SYST-HOST or from the call of CL_ABAP_SYST=>GET_HOST_NAME( ) is compared with a fixed value. To do this, it views the logical condition of the predefined functions BOOLC or BOOLX and the following statements:

        1. IF, ELSEIF
        2. CASE, WHEN
        3. CHECK
        4. ASSERT

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Hard-coded system ID – 11S2

Hard-coded system ID, possibly from forgotten test code or an indication of a back door

System ID queries in ABAP indicate security problems. System-specific code often presents a back door for attackers.

Procedure

Check whether the system ID query could possibly indicate a back door. Remove these back doors.

Remove any system-specific code that is not required to run the program.

Some applications cases require system-specific code. However, there is currently no method of detecting these code sections and excluding them from the checks.

Check whether suitable customizing or a suitable API could help to apply distinct behavior to individual systems in these cases.

All occurrences are reported in which the current system ID from the system fields SY-SYSID and SYST-SYSID are compared with a fixed value. To do this, it views the logical condition of the predefined functions BOOLC or BOOLX and the following statements:

  1. IF, ELSEIF
  2. CASE, WHEN
  3. CHECK
  4. ASSERT

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Hard-coded client – 11S3

Hard-coded client from forgotten test Code or that could indicate a back door.

Client queries in ABAP indicate security problems. Client-specific code often presents a back door for attackers.

Procedure

Check whether the client number query could possibly indicate a back door. Remove any back doors.

Remove any client-dependent code that is not required to run the program.

Some applications cases require client-specific code. However, there is currently no method of detecting these code sections and excluding them from the checks.

Check whether suitable customizing or a suitable API could help to apply distinct behavior to individual clients in these cases.

All occurrences are reported in which the current client from the system fields SY-MANDT and SYST-MANDT or from the call of

CL_ABAP_SYST=>GET_CLIENT( ) is compared with a fixed value. To do this, it views the logical condition of the predefined functions BOOLC or BOOLX and the following statements:

  1. IF, ELSEIF
  2. CASE, WHEN
  3. CHECK
  4. ASSERT

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

Comparison of a specific registered system variable with a fixed value – 11S4

System variable compared with a hard-coded value from forgotten test code or that could indicate a back door

A comparison between one or more registered system variables and a hard-coded value indicates a security problem, since the code dependent on these system variables could be a back door.

Procedure

Check whether the system variable query could possibly indicate a back door. Remove these back doors.

Remove any code dependent on these system variables that is not required to run the program.

Some application cases require code dependent on these system variables. However, there is currently no method of detecting these code sections and excluding them from the checks.

Check whether suitable customizing or a suitable API could help to apply distinct behavior in these cases, depending on the registered system variables.

The system variables in question were registered using the BAdI SLIN_BADI_SEC_BACKDOOR as described in the documentation.

All occurrences are reported in which the registered system variables from the system structures SY and SYST are compared with a fixed value. To do this, it views the logical condition of the predefined functions BOOLC or BOOLX and the following statements:

  1. IF, ELSEIF
  2. CASE, WHEN
  3. CHECK
  4. ASSERT

If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.

 

 

To report this post you need to login first.

3 Comments

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

Leave a Reply