ABAP SQL Injection - How To Protect Your Code Right?
ABAP SQL Injection - How To Protect Your Code Right?
In ABAP, there are several statements where SQL injection can occur:
In this example, in the WHERE statement a user-controlled parameter input is used. If an attacker is
able to define data reading criteria, he or she will be able to get access to critical data.
An attacker can pass the string ‘anything’ OR ‘1’=’1’ to the variable input. As a result, the SQL
statement will look as follows:
SELECT fieldlist FROM table1 WHERE some field =’anything’ OR '1=1'
As ‘1’=’1′ is always true, all records from the database will be shown. Besides, an attacker can use a
UNION statement to combine two different SQL requests and get data from other tables.
Injections in System Functions
Another dangerous construction is related to the system functions “C_DB_EXECUTE” and “C_DB_FUNCTION”. These functions are used to call for
database commands directly:
The field ‘STATTXT‘ contains a SQL statement. The variable STMT is declared as a parameter and transmitted to this field. Therefore, an attacker can
pass a specially crafted SQL statement to the variable STMT and reach the malicious goals by executing it.
Methods “EXECUTE_UPDATE”, “EXECUTE_DDL” and “EXECUTE_QUERY” of the “CL_SQL_STATEMENT” class also can be sources of SQL injections:
By exploiting a SQL injection vulnerability, an attacker can get access to business-critical information or system data. Moreover, a denial of service
attack can be performed by executing a complicated SQL statement. For example, a perpetrator can pass a query, which will search for a certain
pattern through all the records in the database (via a LIKE statement). This query will take a long time to run and, at the same time, will significantly
increase the server load, thus blocking access to the application for legitimate users.
SAP ADBC Injections
There is also a risk of a SQL injection when ABAP Database Connectivity (ADBC) is used. SQL statements are passed as strings
to the objects of the ADBC class and then to the database system. An attack is possible if all parts of one of these SQL
statements originate from outside of the program to the following methods:
•create_query
•get_persistent_by_query
•execute_query
•execute_update
•execute_ddl
•execute_procedure
•The variable ‘key’ passes from a request to the method ‘execute_query’ without validation. An attack example is similar to one described in
the Open SQL injection section.
SAP AMDP Injections
With new power comes new responsibility; thus, when working with the most powerful database, namely
SAP HANA, you have to pay close attention to its security.
When ABAP Managed Database Procedures (AMDP) is used, database procedures are created and called
that are currently implemented in SQL Script for the SAP HANA database. Risks are incurred whenever a
database procedure contains dynamic parts.
This method uses the SQL Script statement EXEC in the SAP HANA database to execute a SQL specified as a
character string into which the input parameter seats are merged. In this example, the value in the
SEATSOCC column is increased by the value of the parameter seats, which is passed unchecked. An
attacker can send the string 2, seatsmax = seatsmax + 10 to this parameter and change the value in the
SEATMAX column as well. A method like this should be classified as a potential risk since the input
parameter is not checked. If possible, an input check should be implemented in the SQL Script directly
before the statement EXEC is executed.
How To Identify SQL-Injection Vulnerabilities
during Code Profiling?
SAP standard offers a range of tools in order to ensure code violations can be identified. The
Abap Test Cockpit (ATC) is a check framework which allow static checks and unit tests for Abap
programs.
ATC is also the umbrella above SAP Code Inspector (SCI), the extended syntax check (SLIN) and
the SAP Code Vulnerability Analyzer (CVA).
Especially this last one, the SAP code vulnerability analyzer, serves a great purpose when it
comes to code security. Although SAP ships CVA as standard with recent Net Weaver releases
its use unfortunately comes at a very steep license cost.
Rules to Protect Sensitive Data
Always validate input for dynamic statements
Use static open SQL statements where possible
The following manipulation or unauthorized data access attacks of dynamic open SQL are possible
:
Manipulation of the dynamic WHERE condition
Manipulation of the SET clause in the statement UPDATE
Illegal read access to a database table with a SELECT statement
Illegal read access to table columns
Illegal use of columns in a dynamic GROUP BY clause
Illegal use of columns in a dynamic HAVING clause
If dynamic SQL statements used, then use class CL_ABAP_DYN_PRG to implement input checks
and escape the input for the active clauses. The usage of this class and its methods displayed in
following example programs: