Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Code Vulnerability Analyzer Checks

peterbarker
Product and Topic Expert
Product and Topic Expert
‎01-19-2017 9:07 AM

The purpose of this blog


This blog lists the checks that SAP Code Vulnerability Analyzer 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 Code Vulnerability Analyzer" 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)

Insufficient authorization checks or 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 allow lists) 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 an allow list 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.


Potential manipulation of the dynamic WHERE condition of a wrapped SQL statement 110A


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

In the case in question, external data is passed to a procedure (for example, the function module RFC_READ_TABLE), which itself uses the data within a dynamic clause of an OpenSQL 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.

The dynamic WHERE clause makes it possible for attackers to inject additional OR conditions that increase the volume of data selected in unexpected ways. If fewer than 11 characters can be injected in the dynamic WHERE clause, no meaningful attack can take place and no message appears.

If an attacker can inject at least 50 characters in the dynamic WHERE clause, they may contain a subquery enabling any number of further tables to be accessed.

Further procedures that wrap vulnerable statements can themselves be registered as vulnerable using the BAdI SLIN_BADI_VULN_PROCEDURES. All registered vulnerable procedures can be displayed using the report RSLIN_SEC_DISPLAY_VULN_PROC. 

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 instead of the original input value):

  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


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.

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.

How is the check done?


A local data flow analysis is performed.


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


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

In the case in question, external data is passed to a procedure (for example, the function module RFC_READ_TABLE), which itself uses the data within a dynamic clause of an OpenSQL 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.

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

Further procedures that wrap vulnerable statements can themselves be registered as vulnerable using the BAdI SLIN_BADI_VULN_PROCEDURES. All registered vulnerable procedures can be displayed using the report RSLIN_SEC_DISPLAY_VULN_PROC. 

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 instead of the original input value):

  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.

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.

How is the check done?


A local data flow analysis is performed.


FILTER addition of the statement OPEN DATASET used 1107


The addition FILTER of the statement OPEN DATASET can be used to pass commands to the operating system. For security reasons, this addition can no longer be used.

Procedure


Do not use the addition FILTER.
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

  • Permits the definition of check modules, for example for checking for valid values

  • 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.
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.

How is the check done?


All uses of the addition FILTER of the statement OPEN DATASET are reported.


Potentially important reports deleted from the ABAP repository 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 and various other procedures can be used to delete or overwrite programs from the ABAP repository. If the name of the deleted or overwritten program is derived from user input, an attacker can potentially delete or overwrite ABAP programs required by the application or the system and hence impair system functions.

Procedure


If at all possible, the names of deleted or overwritten programs 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.

How is the check done?


All those DELETE REPORT statements are checked where it is not possible to know statically that only the inactive version of a program is deleted using the addition STATE = 'I'. Furthermore, calls of the function module RS_DELETE_PROGRAM are checked, plus a range of other procedures that delete or overwrite programs.
A local data flow analysis is performed.


Replacement of potentially important reports deleted from the ABAP repository by the statement INSERT REPORT 1111


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

Procedure


If at all possible, the names of overwritten programs should not be derived from user input for security reasons. If this is absolutely necessary, the input data must be verified using suitable checks first.
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 instead of the original input value):

  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 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.

How is the check done?


For all INSERT REPORT statements, the system checks whether the specified program name contains dynamic parts that are taken from external data without being checked.
A local data flow analysis is performed.


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, an allow list 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.


Dynamic CALL TRANSACTION without authorization check 1114E


What is checked?


When a transaction is started from the user interface or by executing the ABAP statement 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 statement 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 source code. This could present a security risk.
A check on valid transaction names 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, it should be noted that the table TCDCOUPLES is respected for the 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a check on valid values).
SAP recommends that the entries in the table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.
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.

How is the check done?


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 without authorization check and without check on valid transaction names 1114F


What is checked?


Security problems can occur wherever external data (such as user input) is processed further without being checked.
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 statement 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 statement 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, it should be noted that the table TCDCOUPLES is respected for the 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a check on valid values).
SAP recommends that the entries in the table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.


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.


Potential read performed using an invalid secondary database connection in an Open SQL statement - 1121


Security problems can occur wherever external data (such as user input) is processed further without being checked.
Here, 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.
Attackers can potentially use dynamically specified connections to execute operations using a secondary database connection.

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.

  1. CHECK_WHITELIST_STR

  2. CHECK_WHITELIST_TAB


Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
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.
A local data flow analysis is performed.


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 an allow list 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.


Potentially manipulated HTML page in HTML control - 1135


Security problems can occur wherever external data (such as user input) is processed further without being checked.
In some cases, external data is used without encoding to generate a dynamic HTML page and then sent to the front end (browser). This makes it possible for an attacker to send unwanted scripts to the front end (browser) of the victim (using unwanted input) and execute malicious code there. In this case, this is known as cross-site scripting (XSS).
In the case in question, it is possible that a manipulated HTML page was sent to a HTML control (CL_GUI_HTML_VIEWER).

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.

Internal SAP link: https://wiki.wdf.sap.corp/wiki/display/NWCUIAMSIM/XSS+Secure+Programming+Guide

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

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.

How is the check done?


INCLUDE CHAPBC_SLINSEC_DATAFLOW OBJECT DOKU ID HY


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 allow list 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 allow list 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a allow list 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using an allow list 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.

An allow list 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using an allow list 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 without authorization check and without check on valid transaction names – 114F


What is checked


Dynamic CALL TRANSACTION without authorization check and without an allow list 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using an allow list 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 potentially incomplete authorization check – 114G


What is checked?


Security problems can occur wherever external data (such as user input) is processed further without being checked.
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 statement 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 statement 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, it should be noted that the table TCDCOUPLES is respected for the 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a check on valid values).
SAP recommends that the entries in the 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 appropriately 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 instead of the original input value):
1. CHECK_WHITELIST_STR
2. CHECK_WHITELIST_TAB
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
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.

How is the check done


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 without authorization check – 114H


What is checked?


When a transaction is started from the user interface or by executing the ABAP statement 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 statement 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 source code. This could present a security risk.
No vulnerable data source was found for the transaction name. This means that the name of the called transaction most probably cannot be manipulated from outside.

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, it should be noted that the table TCDCOUPLES is respected for the 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a check on valid values).
SAP recommends that the entries in the table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.
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.

How is the check done


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 without authorization check – 114I


What is checked?


When a transaction is started from the user interface or by executing the ABAP statement 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 statement 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 source code. This could present a security risk.
No vulnerable data source was found for the transaction name. This means that the name of the called transaction most probably cannot be manipulated from outside.

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, it should be noted that the table TCDCOUPLES is respected for the 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 TRANSACTIONS, it is only acceptable to skip the authorization check if the set of callable transactions is restricted (usually by using a check on valid values).
SAP recommends that the entries in the table TCDCOUPLES (transaction SE97) are no longer used to control the behavior.
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.

How is the check done


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.


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


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

Once the security-relevant subroutine (FORM routine) has been called, a check must be run to verify that execution was successful. In general this is an evaluation of the corresponding output parameter or a check of system field SY-SUBRC, if the subroutine uses this as an implicit output parameter.

Procedure


Insert an evaluation of the return value (for example, SY-SUBRC) with an appropriate response (for example, error message or 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.

A check is run to verify if an evaluation is performed after an external security-relevant subroutine is called.

The check can be expanded by using a BAdI.

Further procedures can be registered as security-relevant using the BAdI SLIN_BADI_SEC_PROCEDURES. All registered security-relevant procedures 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 or AUTHORITY-CHECK. Statements such as ENDIF, simple assignments (that do not modify the return value), or comments are permitted before reads. If there is an empty IF/ENDIF block after the procedure call, a problem is registered.


Potentially security-relevant procedure without registration - 1163


Potentially security-relevant procedure without registration

Directly after the call of an authorization check using the statement AUTHORITY-CHECK or after the call of a similar procedure, the result of the call in question must be checked. To do this after the statement AUTHORITY-CHECK, the system field SY-SUBRC must be queried. After a procedure is called, the corresponding output parameter must be queried.

In some cases, the authorization check is made in a procedure A and the value of SY-SUBRC (or a corresponding output parameter) returned to its own caller B. This delegates the job of responding appropriately to a failed authorization check to the the caller B. The procedure A becomes a security-relevant procedure and it must now be ensured that all callers of the procedure A check the returned result (in exactly the way they would if they had called the statement AUTHORITY-CHECK themselves).

In this case, we know that a globally visible procedure delegates the evaluation of the result of an authorization check to its calling programs. Therefore the procedure should be registered as security-relevant in CVA, so that all its calling programs can be checked, to verify that they evaluate the returned result.

Example


The function module is a global procedure, which wraps statement AUTHORITY-CHECK. The successful execution check is delegated to the calling program.
FUNCTION Z_AUTHORITY_CHECK.
...
*" EXCEPTIONS
*" NO_AUTHORITY

...

AUTHORITY-CHECK OBJECT 'S_TCODE'
ID 'TCD' FIELD I_TCODE.

IF SY-SUBRC 0.
MESSAGE eXXX(XX) RAISING NO_AUTHORITY.
ENDIF.

ENDFUNCTION.

Procedure


First check whether it is necessary to use the global procedure. Switching to a local procedure (for example, from a public to a private method) means that 1163 messages are no longer displayed.

If it is not possible to switch, you should register the procedure as security-relevant using BAdl SLIN_BADI_SEC_PROCEDURES. Once the procedure has been registered as security-relevant, 1163 messages are no longer displayed. Instead, new security messages can now be displayed in all programs that use the registered
If it is not possible to switch, you should register the procedure as security-relevant using BAdl SLIN_BADI_SEC_PROCEDURES. Once the procedure has been registered as security-relevant, 1163 messages are no longer displayed. Instead, new security messages can now be displayed in all programs that use the registered procedure.

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.

This check verifies whether the return value (for example, SY-SUBRC) is read immediately after the procedure call or AUTHORITY-CHECK. In the case in question, this return is either reused as the return code of the current procedure or a classic exception is raised dependent on the return code (which creates a new return code). This means that the handling of the value is delegated to the caller of the current procedure.


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


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

Directly after the call of an authorization check using the statement AUTHORITY-CHECK or after the call of a similar procedure, the result of the call in question must be checked. To do this after the statement AUTHORITY-CHECK, the system field SY-SUBRC must be queried. After a procedure is called, the corresponding output parameter must be queried.

In some cases, the authorization check is made in a procedure A and the value of SY-SUBRC (or a corresponding output parameter) returned to its own caller B. This delegates the job of responding appropriately to a failed authorization check to the the caller B. The procedure A becomes a security-relevant procedure and it must now be ensured that all callers of the procedure A check the returned result (in exactly the way they would if they had called the statement AUTHORITY-CHECK themselves).

Procedure


After the procedure call, run the evaluation of the return value with an appropriate response (for example, error message or 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.

This check verifies whether the return value (for example, SY-SUBRC) is read immediately after the procedure call or AUTHORITY-CHECK. In the case in question, this return is either reused as the return code of the current procedure or a classic exception is raised dependent on the return code (which creates a new return code). This means that the handling of the value is delegated to the caller of the current procedure.


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 allow lists) 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 names of C functions.

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 instead of the original input value):







        1. CHECK_WHITELIST_STR

        2. CHECK_WHITELIST_TAB








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

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.

How is the check done?


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


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 an allow list 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 allow list 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( ).

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 entered in database table TPGP and hence valid). The authorization group can be entered in the attributes 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.

How is the check done?


The report is scanned for certain authorization checks and risky statements (see below), which entails the report code (including form routines, dynpro modules, functions calls, and method calls) being scanned.
These calls are traced recursively up to a maximum search depth of 10 compilation units. (This means that calls within a compilation unit are ignored.) Any authorization checks at a greater depth are not found.
If a program or a procedure, which does not belong to SAP_BASIS, calls a procedure from SAP_BASIS, then this call is not traced. (Reason: From a semantic perspective, authorization checks in SAP_BASIS have nothing to do with the required authorization check in the application.)

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'

  • Function call CALL FUNCTION 'VIEW_AUTHORITY_CHECK'

  • 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.

The following statements are classified as dangerous:

  • DELETE from a database table (Open SQL), DELETE DATASET, DELETE DYNPRO, DELETE REPORT, DELETE TEXTPOOL, DELETE FROM DATABASE, DELETE FROM SHARED MEMORY, DELETE FROM SHARED BUFFER

  • EXPORT TO DATABASE, EXPORT TO DATASET, EXPORT TO SHARED MEMORY, EXPORT TO SHARED BUFFER

  • GENERATE SUBROUTINE POOL

  • INSERT in a database table (Open SQL), INSERT REPORT, INSERT TEXTPOOL

  • MODIFY in a database table (Open SQL), MODIFY LINE, MODIFY SCREEN

  • SELECT from a database table not in the delivery class C, E, G, S, or W (Open SQL)

  • TRANSFER

  • TRUNCATE

  • UPDATE

  • WITH: Reads from a database table not in the delivery class C, E, G, S, or W (Open SQL)



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( ).

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.

How is the check done?


The RFC function module is scanned for certain authorization checks and risky statements (see below), which entails the function code (including form routines, dynpro modules, functions calls, and method calls) being scanned.
These calls are traced recursively up to a maximum search depth of 10 compilation units. (This means that calls within a compilation unit are ignored.) Any authorization checks at a greater depth are not found.
If a program or a procedure, which does not belong to SAP_BASIS, calls a procedure from SAP_BASIS, then this call is not traced. (Reason: From a semantic perspective, authorization checks in SAP_BASIS have nothing to do with the required authorization check in the application.)
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'

  • Function call: CALL FUNCTION 'VIEW AUTHORITY CHECK'

  • Method call: CALL METHOD CL_SACF=>AUTH_CHECK_SPEC


Authorization checks against authorization object S_RFC are not accepted here since this authorization object is checked automatically against every RFC call.
Authorization checks against authorization object B_BUP_PCPT are also not accepted.

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.
The following statements are classified as dangerous:

  • DELETE from a database table (Open SQL), DELETE DATASET, DELETE DYNPRO, DELETE REPORT, DELETE TEXTPOOL, DELETE FROM DATABASE, DELETE FROM SHARED MEMORY, DELETE FROM SHARED BUFFER

  • EXPORT TO DATABASE, EXPORT TO DATASET, EXPORT TO SHARED MEMORY, EXPORT TO SHARED BUFFER

  • GENERATE SUBROUTINE POOL

  • INSERT in a database table (Open SQL), INSERT REPORT, INSERT TEXTPOOL

  • MODIFY in a database table (Open SQL), MODIFY LINE, MODIFY SCREEN

  • SELECT from a database table not in the delivery class C, E, G, S, or W (Open SQL)

  • TRANSFER

  • TRUNCATE

  • UPDATE

  • WITH: Reads from a database table not in the delivery class C, E, G, S, or W (Open SQL)


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 a BOR object – 11A3


Authorization checks should be used to secure BOR objects (Business Object Repository) against being called by unauthorized users.

Procedure


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

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.

How is the check done?


Non-active BOR objects are not analyzed.
The ExistenceCheck method of the BOR object is scanned for specific authorization checks, including the code of the method and its form routines, dynpro modules, function calls, and method calls.
These calls are traced recursively up to a maximum search depth of 10 compilation units. (This means that calls within a compilation unit are ignored.) Any authorization checks at a greater depth are not found.
If a program or a procedure, which does not belong to SAP_BASIS, calls a procedure from SAP_BASIS, then this call is not traced. (Reason: From a semantic perspective, authorization checks in SAP_BASIS have nothing to do with the required authorization check in the application.)

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'

  • Function call: CALL FUNCTION 'VIEW AUTHORITY CHECK'

  • Method call: CALL METHOD CL_SACF=>AUTH_CHECK_SPEC


Authorization checks against authorization object B_BUP_PCPT are not accepted.

Unlike other checks for missing authorization checks (for example, in reports or RFC function modules) dangerous statements are not covered by this check. This means that missing authorization checks are also registered if no dangerous statement is found.


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.


Field with hard coded password - 11K2


A variable or constant with a hard coded password exists. 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


FUNCTION 'GET_USER_PASSWORD'
*"--------------------------------------
*"*"Local Interface:
*" EXPORTING
*" VALUE(EV_PASSWORD) TYPE STRING
*"---------------------------------------

EV_PASSWORD = 'Abcd1234'

ENDFUNCTION.

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.

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.

All password-relevant fields that have a hard-coded value are reported. A field is a password-relevant field if it follows a specific naming convention or has a specific type.


Field with Base64-encoded password - 11K3


There is a variable with a Base64-encoded password. This can be an indication that the password was not sent or saved securely.

Example


L_ENCRYPTED_PASSWORD = CL_HTTP_UTILITY=>ENCODE_BASE64( I_PASSWORD ).

Procedure


Do not use Base64 as the encryption algorithm. Base64 encodes and does not encrypt. If possible, use the default methods for authentication and saving passwords.

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.

All Base64-encoded password-relevant fields are highlighted. A field is a password-relevant field if it follows a specific naming convention or has a specific type.

The following Base64 encoding APIs are analyzed:

CL_HTTP_UTILITY=>ENCODE_BASE64

CL_HTTP_UTILITY=>ENCODE_X_BASE64

SSFC_BASE64_ENCODE


Potential valid invalidation using the class CL_ABAP_DYN_PRG - 11N1


The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. In this case, the validation may have no effect and may therefore be invalid.

Example


" - Incorrect validation
TRY.
tab_name =
cl_abap_dyn_prg=>check_table_or_view_name_str(
val = tab_name
packages = 'SABAPDEMOS' ).
CATCH cx_abap_not_a_table cx_abap_not_in_package.
"TODO...
ENDTRY.

SELECT SINGLE name FROM (tab_name) INTO lv_custname
WHERE id = '22'.

Procedure


Note the following notes for the selected elements:

  • React appropriately to validation errors by handling the corresponding exception.



  • Do not use the same variable as an argument for EXPORTING and RETURNING parameters. Only use the RETURNING value in further processing. This ensures that an unchecked entry cannot be processed further.


Example


TRY.
" - Correct validation
tab_name_checked
= cl_abap_dyn_prg=>check_table_or_view_name_str(
val = tab_name
packages = 'SABAPDEMOS' ).
CATCH cx_abap_not_a_table.
MESSAGE 'Table is not allowed' TYPE 'E'.
CATCH cx_abap_not_in_package.
MESSAGE 'Table is not in package' TYPE 'E'.
ENDTRY.

SELECT SINGLE name FROM (tab_name_checked) INTO lv_custname
WHERE id = '22'.

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.

How is the check done?


All method calls of CL_ABAP_DYN_PRG are analyzed and any suspicious calls are reported.


Potential valid invalidation (tautological value check) with class CL_ABAP_DYN_PRG - 11N3


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 following methods can be used to check the input value against a list of allowed values:

  • CHECK_WHITELIST_STR



  • CHECK_WHITELIST_TAB



  • MASS_CHECK_WHITELIST_TAB



  • MASS_CHECK_WHITELIST_STR


In this case, the validation may have no effect and may therefore be invalid because the list of permitted values was probably derived from the value to be checked or is empty.

Example


" Incorrect validation (Tautological AllowList)

allow_list = tab_name.

tab_name =
cl_abap_dyn_prg=>check_whitelist_str( val       = tab_name
whitelist = allow_list ).

SELECT SINGLE name FROM (tab_name) INTO lv_custname
WHERE id = '22'.

Procedure


Note the following notes for the selected elements:

  • The list of allowed values must not be derived from the value to be checked (tautological case).



  • If possible, use other validation methods from the class CL_ABAP_DYN_PRG instead of the methods CHECK_WHITELIST_STR, CHECK_WHITELIST_TAB, MASS_CHECK_WHITELIST_TAB and MASS_CHECK_WHITELIST_STR.



  • React appropriately to validation errors by handling the corresponding exception.



  • Do not use the same variable as an argument for EXPORTING and RETURNING parameters. Only use the RETURNING value in further processing. This ensures that an unchecked entry cannot be processed further. If exception handling is missing at the same time, an entry could otherwise be processed further even if the value to be checked is not contained in the list of permitted values.


Example


TRY.
" Correct validation with CHECK_WHITELIST_STR

allow_list = cl_some_class=>get_allowed_tables( ).

tab_name_checked =
cl_abap_dyn_prg=>check_whitelist_str( val       = tab_name
whitelist = allow_list ).
CATCH cx_abap_not_in_whitelist.
MESSAGE 'Table not allowed' TYPE 'E'.
ENDTRY.

" Or Correct validation with another method
TRY.

tab_name_checked
= cl_abap_dyn_prg=>check_table_or_view_name_str(
val      = tab_name
packages = 'SABAPDEMOS' ).

CATCH cx_abap_not_a_table.
MESSAGE 'Table is not allowed' TYPE 'E'.
CATCH cx_abap_not_in_package.
MESSAGE 'Table is not in package' TYPE 'E'.
ENDTRY.

SELECT SINGLE name FROM (tab_name_checked) INTO lv_custname
WHERE id = '22'.

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.

How is the check done?


All method calls of CL_ABAP_DYN_PRG are analyzed and any suspicious calls are reported.


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 an allow list before being used in HTTP redirects.

In this case, the automated check views the allow list 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.


Potential Reverse Tabnabbing – 11R1


Reverse tabnabbing indicates attacks in which a linked page can overwrite the original page, for example, by replacing it with a phishing page. The user saw the correct page which means that he or she may not noticed that the page was switched. If the user enters confidential data on the switched page, they are sent to the phishing page and not to the original page.

See https://owasp.org/www-community/attacks/Reverse_Tabnabbing

Example



  1. Code on vulnerable page:


<a href="https://bad_evil.com" target="_blank">HTML Link </ a>

<button onclick="window.open('https://bad_evil.com')">
Vulnerable target using javascript
</button>

  1. Code on malicious page:


<script>
if (window.opener) {
window.opener.location = "https://phish.bad_evil.com";
}
</script>

Procedure


In the case of HTML links, add the attribute rel = "noopener noreferrer" to each link.

In the case of JavaScript, use the function window.open with 'noopener, noreferrer'

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.

How is the check done?


The check analyzes character literals in the ABAP source code that contain 'TARGET="_BLANK"' or 'WINDOW.OPEN'. An error occurs if 'NOOPENER NOREFERRER' is not found in the same statement.


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.


Undocumented profile parameter used – 11SP


Using undocumented profile parameters indicates a security problem, a potential back door.

Procedure


Use only documented profile parameters.

How is the check done?


All usages of profile parameters for which there is no documentation in transaction RZ11 are reported.

 

 
20 Comments
Labels in this area
Popular Blog Posts