Code Vulnerability Analyzer Checks
The purpose of this blog
This blog lists the checks that SAP NetWeaver AS, Add-On for Code Vulnerability Analysis provides.
The checks are made available with specific releases of SAP NetWeaver. For information as to which checks are available with which releases, please read note 1921820.
Background about Code Vulnerability Analyzer
The product “SAP NetWeaver Application Server add-on for code vulnerability analysis” is available for carrying out security checks. This is also called the code vulnerability analyzer (CVA). The CVA carries out a static analysis of the ABAP source code and reports possible security risks.
The CVA is a product in its own right and is subject to separate remuneration. If you enable the execution of the security checks, additional license costs are incurred.
You can allow the execution of system-wide security checks with the report RSLIN_SEC_LICENSE_SETUP. To carry out this step, you require authorization to make changes to global ATC check variants. Before activating the checks, make sure that you possess a valid license for the product. If in doubt, contact your sales representative at SAP.
Once the security checks are enabled, you can execute them in the ABAP Test Cockpit (ATC), the Code Inspector (SCI), and the extended program check. In the system, the security checks are sometimes called “Security Analyses in Extended Program Check (SLIN_SEC)”. We recommend that you execute the security checks via the ATC only. This is possible for automatic mass runs and in the ABAP development environment for individual objects.
SAP Note 1921820 describes the releases and Support Packages with which the code vulnerability analyzer is available. SAP Note 1949276 describes restrictions pertaining to the functional scope. The documentation for the report RSLIN_SEC_LICENSE_SETUP describes the individual security checks in more detail, among other things.
General points about security common to some of all of the checks below
Security problems can occur wherever external data (such as user input) is processed further without being checked.
Sometimes external data is used within a dynamic clause of an OPEN SQL statement. This could enable potential attackers to gain unauthorized access to the SAP database of the system by making unexpected input. This is known as an SQL injection.
Sometimes external data is used as a file name to open or delete files on the application server. This can give potential attackers access to the file system of the application server, so enabling them to access confidential information, modify file contents, and change the way the system behaves. This is known as directory traversal.
For information about a specific check, click on the appropriate link below:
Manipulation of dynamic Open SQL (Open SQL Injection)
- Potential manipulation of the dynamic WHERE condition – 1101
- Potential manipulation of a dynamic WHERE condition using the parameter I_FILTER of the object services method CREATE_QUERY – 1122
- Potential manipulation of the SET clause in the statement UPDATE – 1112
- Potential read performed on an illegal database table in a SELECT statement – 1118
- Potential read performed on an illegal database table in a modifying OpenSQL statement- 1120
- Potential read performed on invalid table columns – 1114
- Potential use of illegal columns in a dynamic GROUP BY clause – 1116
- Potential use of illegal columns in a dynamic HAVING clause – 1117
Manipulation of SQL statements (Native SQL Injection)
- Potential injection of harmful SQL statements or clauses in execution of DDL statements in ADBC – 1128
- Potential injection of harmful SQL statements or clauses in execution of DML statements in ADBC – 1130
- Potential injection of malicious SQL statements or clauses when calling an appropriate API – 11D1
Manipulation of dynamically generated ABAP code (ABAP Command Injections)
- Potential injection of harmful code in the statements INSERT REPORT and GENERATE SUBROUTINE POOL – 1108
- Potential injection of harmful code when the RFC-enabled function module RFC_ABAP_INSTALL_AND_RUN was called- 1109
- Potential manipulation of the dynamic WHERE condition in an internal table – 1190
Manipulation in dynamic calls (Call Injections)
- Potential manipulation of the dynamic WHERE condition – 1101
- Potential manipulation of a dynamic WHERE condition using the parameter I_FILTER of the object services method CREATE_QUERY – 1122
- Potential manipulation of the SET clause in the statement UPDATE – 1112
- Potential read performed on an illegal database table in a SELECT statement – 1118
- Potential read performed on an illegal database table in a modifying OpenSQL statement – 1120
- Potential read performed on invalid table columns – 1114
- Potential use of illegal columns in a dynamic GROUP BY clause – 1116
- Potential use of illegal columns in a dynamic HAVING clause – 1117
Injections of operating system commands
- Statement CALL “SYSTEM” used – 1170
- Potential manipulation in the FILTER addition of the statement OPEN DATASET – 1106
Potential unauthorized access to directories and files (Directory Traversal)
- Potential manipulation of the file name in the statement OPEN DATASET or DELETE DATASET – 1104
- Potential manipulation of the file name in the method CREATE_UTF8_FILE_WITH_BOM of the class CL_ABAP_FILE_UTILITIES – 1124
- Non-secure parameter of the function module FILE_GET_NAME used – 1126
Insuffient authorization checks of user administration bypassed
- SY_SUBRC not evaluated after the statement AUTHORITY-CHECK – 1160
- Return value (for example, SY-SUBRC) not evaluated after a security-relevant method was called – 1161
- Return value (for example, SY-SUBRC) not evaluated after a security-relevant function was called – 1165
- AUTHORITY-CHECK with explicitly specified user name – 1180
- AUTHORITY-CHECK for SY-UNAME – 1181
- Static CALL TRANSACTION without check on authorization from the transaction editor – 114A
- Static CALL TRANSACTION without check on authorization object S TCODE – 114B
- Static CALL TRANSACTION without authorization check – 114C
- Static CALL TRANSACTION without authorization check in the case of restricted functions – 114D
- Potentially missing authorization check in a report – 11A1
- Potentially missing authorization check in an RFC function module – 11A2
Potential back doors
- Hard-coded user name possibly from undeleted test code or an indication of a back door- 0821
- Hard-coded host name sy-host, possibly from undeleted test code or an indication of a back door- 11S1
- Hard-coded system ID sy-sysid, possibly from undeleted test code or an indication of a back door – 11S2
- Hard-coded client sy-mandt, possibly from undeleted test code or an indication of a back door- 11S3
- System variable sy-xxxx compared with a hard-coded value from forgotton test code or that could indicate a back door – 11S4
- Procedure call with hard-coded password – 11K1
Possible attacks using Web technologies
- Potential risk of cross-site scripting – 1132
- Potential reflected cross-site scripting – 1134
- Potential unvalidated URL redirect – 11P1
- Obsolete escape method – 1150
- Missing Content Check During HTTP Upload – 11F1
Further checks
- Statement COMMUNICATION used – 11C1
- Read performed on sensitive database table – 11G0
- Write performed on sensitive database table – 11G1
- Potentially important reports deleted from the ABAP repository – 1110
Here is a list by check number in ascending order:
- Hard-coded user name – 0821
- Possible SQL injection (WHERE condition) – 1101
- Possible directory traversal – 1104
- Possible system command injection (addition FILTER) – 1106
- Possible ABAP command injection – 1108
- Possible ABAP command injection via RFC call – 1109
- Possible SQL injection (table name when writing) – 1110
- Possible SQL injection (SET clause) – 1112
- Possible SQL injection (column names) – 1114
- Possible SQL injection (GROUP BY clause) – 1116
- Possible SQL injection (HAVING clause) – 1117
- Possible SQL injection (table name when reading) – 1118
- Possible SQL injection (table name when writing) – 1120
- Possible SQL injection via object services – 1122
- Possible Directory Traversal via file utilities class – 1124
- Potential directory traversal due to insecure parameters – 1126
- Possible SQL injection via ADBC (DDL) – 1128
- Possible SQL injection via ADBC (DML) – 1130
- Possible cross-site scripting – 1132
- Potential reflected cross-site scripting – 1134
- User-controlled dynamic CALL FUNCTION via RFC – 1140
- User-controlled dynamic program unit call – 1141
- User-controlled dynamic CALL TRANSACTION – 1142
- User-controlled dynamic LEAVE TO TRANSACTION – 1143
- Dynamic function module call controllable from UI or via RFC – 1144
- Static CALL TRANSACTION without check of authorization object from SE93 – 114A
- Static CALL TRANSACTION without check of authorization object S TCODE – 114B
- Static CALL TRANSACTION without authorization check – 114C
- Static CALL TRANSACTION without authorization check (restricted function) – 114D
- Dynamic CALL TRANSACTION without authorization check – 114E
- Dynamic CALL TRANSACTION with data flow and without authorization check – 114F
- Dynamic CALL TRANSACTION with data flow, authorization check of S TCODE – 114G
- Usage of an obsolete escaping method – 1150
- forceEncode=”not specified” for htmlb:content – 1151
- In tag htmlb:content an obsolete design is specified or none at all – 1152
- AUTHORITY-CHECK without processing or sy-subrc – 1160
- Call of a security-relevant method without handling the return value – 1161
- Call of a security-relevant function without processing sy-subrc – 1165
- Call of system function CALL “SYSTEM” – 1170
- System function call with potential user input on FIELD – 1171
- AUTHORITY-CHECK for specified user – 1180
- AUTHORITY-CHECK for SY-UNAME – 1181
- The dynamic WHERE condition allows a potential code injection – 1190
- Potentially missing authorization check in a Report – 11A1
- Potentially missing authorization check in an RFC function module – 11A2
- User of command COMMUNICATION – 11C1
- Potential SQL injection – 11D1
- Missing Content Check During HTTP Upload – 11F1
- Direct read access to critical database tables – 11G0
- Write access to sensitive database tables – 11G1
- Hard-coded password – 11K1
- Open URL redirect – 11P1
- The BSP appplication is not protected against XSRF – 11RF
- Hard-coded host name – 11S1
- Hard-coded system ID – 11S2
- Hard-coded client – 11S3
- Comparison of a specific registered system variable with a fixed value – 11S4
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:
- IF, ELSEIF
- CASE, WHEN
- CHECK
- 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):
- ESCAPE_QUOTES
- ESCAPE_QUOTES_STR
- QUOTE
- QUOTE_STR
- CHECK_CHAR_LITERAL
- CHECK_STRING_LITERAL
- CHECK_INT_VALUE
- CHECK_VARIABLE_NAME
- CHECK_COLUMN_NAME
- CHECK_WHITELIST_STR
- CHECK_WHITELIST_TAB
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
Ranges tables in a WHERE clause are not at risk of SQL injections. However, if technical reasons require ranges tables in WHERE conditions to be converted and then used in a dynamic WHERE clause, it is best to use the function module FREE_SELECTIONS_RANGE_2_WHERE. This module is identified as a secure data source; this is not usually the case in self-programmed conversions.
SAP discourages the use of literals with backquotes (`) in Open SQL statements, even though this is allowed by the syntax. Literals of this type look like string literals in ABAP, but do not have the same attributes. Literals in Open SQL statements are passed to the database, but any blanks at the end of the literals are ignored, which is not the case in ABAP string literals. This is why the use of literals with backquotes (`) can be confusing.
Performs a local data flow analysis.
If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.
Possible directory traversal – 1104
Potential manipulation of the file name in the statement OPEN DATASET or DELETE DATASET
Procedure
Externally defined file names must be validated before a file is opened or deleted. This is done by the function module FILE_VALIDATE_NAME. This function module was made available with the Support Packages or correction instructions listed in SAP Note 1497003. The ABAP keyword documentation contains an example of file name validation.
Another option is to call the function module FILE_GET_NAME_AND_VALIDATE or FILE_GET_NAME. No unchecked data can be included in the parameter LOGICAL_FILENAME here. This means the automated check currently requires LOGICAL_FILENAME to be a constant. In the case of the function module FILE_GET_NAME, no unchecked data can be included in the parameters PARAMETER_1, PARAMETER_2, and PARAMETER_3 either.
The function module FILE_GET_NAME_AND_VALIDATE was made available with SAP Note 1957910.
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
A local data flow analysis is performed.
If the source code position in question does not have any security problems and there is no point in modifying the source code, an exemption should be requested in ATC.
Possible system command injection (addition FILTER) – 1106
Potential manipulation in the FILTER addition of the statement OPEN DATASET
The addition FILTER of the statement OPEN DATASET can be used to pass statements to the operating system. If this addition is filled from input data, potential attackers can inject further statements and modify the behavior of the application server in unexpected ways. These are known as system command injections.
Procedure
First check whether it is absolutely necessary to use the addition FILTER. If this is the case, an input check must be performed. The addition FILTER should not be used to send operating system commands.
If an operating system command call is absolutely necessary, however, the SAPXPG mechanism must be used. This offers increased security due to the following characteristics:
- Abstraction from different operating systems
- Predefined operating system commands
- Stricter handling of parameters
- Allows check modules (such as whitelists) to be defined
- Predefined authorization check
New operating system commands must first be defined using transaction SM69. If possible, omit input values because these can also cause a security problem. The function module SXPG_CALL_SYSTEM can be used to make calls. See System Command Injections for more information.
In some cases, the class CL_ABAP_DYN_PRG can be used to perform a whitelist check. Here, the following methods are sufficient for the machine check in question (if the RETURNING parameter of the method in question is used in further processing):
- CHECK_WHITELIST_STR
- 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):
- ESCAPE_QUOTES
- ESCAPE_QUOTES_STR
- QUOTE
- QUOTE_STR
- CHECK_CHAR_LITERAL
- CHECK_STRING_LITERAL
- CHECK_INT_VALUE
- CHECK_VARIABLE_NAME
- CHECK_COLUMN_NAME
- CHECK_TABLE_OR_VIEW_NAME_STR
- CHECK_TABLE_OR_VIEW_NAME_TAB
- CHECK_TABLE_NAME_STR
- CHECK_TABLE_NAME_TAB
- CHECK_WHITELIST_STR
- 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):
- ESCAPE_QUOTES
- ESCAPE_QUOTES_STR
- QUOTE
- QUOTE_STR
- CHECK_CHAR_LITERAL
- CHECK_STRING_LITERAL
- CHECK_INT_VALUE
- CHECK_VARIABLE_NAME
- CHECK_COLUMN_NAME
- CHECK_TABLE_OR_VIEW_NAME_STR
- CHECK_TABLE_OR_VIEW_NAME_TAB
- CHECK_TABLE_NAME_STR
- CHECK_TABLE_NAME_TAB
- CHECK_WHITELIST_STR
- CHECK_WHITELIST_TAB
Checks on the merged ABAP code passed to the function module RFC_ABAP_INSTALL_AND_RUN are not feasible.
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
Performs a local data flow analysis.
If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.
Possible SQL injection (table Name when writing) 1110
Potentially important reports deleted from the ABAP repository
Security problems can occur wherever external data (such as user input) is processed further without being checked.
The statement DELETE REPORT or the function module RS_DELETE_PROGRAM can be used to delete programs from the ABAP repository. If the name of the deleted program is derived from user input, an attacker can potentially delete ABAP programs required by the application or the system and hence impair system functions.
Procedure
If at all possible, the names of programs deleted using DELETE REPORT or RS_DELETE_PROGRAM should not be derived from user input for security reasons. If this is absolutely necessary, the input data must be checked first accordingly.
The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):
- 1. 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 (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):
- ESCAPE_QUOTES
- ESCAPE_QUOTES_STR
- QUOTE
- QUOTE_STR
- CHECK_CHAR_LITERAL
- CHECK_STRING_LITERAL
- CHECK_INT_VALUE
- CHECK_VARIABLE_NAME
- CHECK_COLUMN_NAME
- CHECK_WHITELIST_STR
- CHECK_WHITELIST_TAB
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
SAP discourages the use of literals with backquotes (`) in Open SQL statements, even though this is allowed by the syntax. Literals of this type look like string literals in ABAP, but do not have the same attributes. Literals in Open SQL statements are passed to the database, but any blanks at the end of the literals are ignored, which is not the case in ABAP string literals. This is why the use of literals with backquotes (`) can be confusing.
Performs a local data flow analysis.
If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.
Possible SQL injection (column names) 1114
Potential read performed on invalid table columns
An attacker may be able to access forbidden columns by specifying the selected columns dynamically. Furthermore, in certain contexts (in INTO CORRESPONDING FIELDS) the attacker could attempt to manipulate the application by renaming columns (“COL1 AS COL2”).
Procedure
First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.
If table columns exist that must not be read in the context in question, a whitelist check is a good idea (see below). In other case, this message is a false alarm.
The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):
- CHECK_WHITELIST_STR
- CHECK_WHITELIST_TAB
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
Performs a local data flow analysis.
If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.
Possible SQL injection (GROUP BY clause) 1116
Potential use of illegal columns in a dynamic GROUP BY clause
Potential attackers can use the dynamic GROUP BY clause to modify the selection in unexpected ways.
Procedure
First check whether it is necessary to use dynamic Open SQL. Switching to static OPEN SQL provides a full solution to the security problem. If this is not possible, the input data must be checked appropriately before being used in dynamic clauses.
The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):
- CHECK_COLUMN_NAME
- CHECK_WHITELIST_STR
- 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):
- ESCAPE_QUOTES
- ESCAPE_QUOTES_STR
- QUOTE
- QUOTE_STR
- CHECK_CHAR_LITERAL
- CHECK_STRING_LITERAL
- CHECK_INT_VALUE
- CHECK_VARIABLE_NAME
- CHECK_COLUMN_NAME
- CHECK_WHITELIST_STR
- 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):
- CHECK_TABLE_OR_VIEW_NAME_STR
- CHECK_TABLE_OR_VIEW_NAME_TAB
- CHECK_TABLE_NAME_STR
- CHECK_TABLE_NAME_TAB
- CHECK_WHITELIST_STR
- 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):
- CHECK_TABLE_OR_VIEW_NAME_STR
- CHECK_TABLE_OR_VIEW_NAME_TAB
- CHECK_TABLE_NAME_STR
- CHECK_TABLE_NAME_TAB
- CHECK_WHITELIST_STR
- CHECK_WHITELIST_TAB
Secure data sources can also be displayed using the report RSLIN_SEC_DISPLAY_BADIS.
Performs a local data flow analysis.
If a source code position is flagged and does not present a security problem and an input check or escape action (for example, using a method from CL_ABAP_DYN_PRG) is not appropriate, an exemption should be requested in ATC.
Possible SQL injection via object services – 1122
Potential manipulation of a dynamic WHERE condition using the parameter I_FILTER of the object services method CREATE_QUERY
In the present case, external data is passed to the method CREATE_QUERY of an object services class. This class handles the data like a dynamic WHERE clause. This makes it possible for attackers to inject additional OR conditions that increase the volume of data selected in unexpected ways. This is known as an SQL injection.
Procedure
The input values for the parameter I_FILTER of the object services method CREATE_QUERY must be made subject to an input check.
The class CL_ABAP_DYN_PRG can be used to implement input checks as described in Validation by Methods of CL_ABAP_DYN_PRG. (The individual methods in the class CL_ABAP_DYN_PRG became available in different Support Packages or SAP Notes. SAP Note 1852318 provides an overview of these methods.) In the case in question, the following methods of this class are viewed as sufficient by the automated check (if the RETURNING parameter of the method in question is used in further processing):
- ESCAPE_QUOTES
- ESCAPE_QUOTES_STR
- QUOTE
- QUOTE_STR
- CHECK_CHAR_LITERAL
- CHECK_STRING_LITERAL
- CHECK_INT_VALUE
- CHECK_VARIABLE_NAME
- CHECK_COLUMN_NAME
- CHECK_WHITELIST_STR
- 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