Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
505 views

ABAP SQL Injection - How To Protect Your Code Right?

SQL injection is a common code injection attack where malicious SQL statements can be inserted via user input to access unauthorized data or impact database operations. In ABAP, SQL injection vulnerabilities can occur in open SQL statements, system functions, ADBC, and AMDP. Developers should validate all user input for dynamic SQL statements, use static statements where possible, and escape any unsafe characters to prevent SQL injection attacks. The SAP Code Vulnerability Analyzer tool can help identify SQL injection and other vulnerabilities during code reviews.

Uploaded by

Vivek V Nair
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
505 views

ABAP SQL Injection - How To Protect Your Code Right?

SQL injection is a common code injection attack where malicious SQL statements can be inserted via user input to access unauthorized data or impact database operations. In ABAP, SQL injection vulnerabilities can occur in open SQL statements, system functions, ADBC, and AMDP. Developers should validate all user input for dynamic SQL statements, use static statements where possible, and escape any unsafe characters to prevent SQL injection attacks. The SAP Code Vulnerability Analyzer tool can help identify SQL injection and other vulnerabilities during code reviews.

Uploaded by

Vivek V Nair
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 8

ABAP SQL Injection – How to

protect your Code right?


SQL injection is one of the most common code injection attack methods,
in which malicious SQL statements are inserted to execute unauthorized
SQL statements in the database, e.g., read data or modify data in the
database. 
Where SQL Injection Occur?

In ABAP, there are several statements where SQL injection can occur:

 Open SQL Injections in SQL Statements (read more below).


 Injections in System functions.
 ADBC Injections.
 AMDP Injections.
Open SQL Injections
 As the name implies, SQL injections can occur in Open SQL statements: SELECT, WHERE, FROM
UPDATE, DELETE, and INSERT.
 Here is an example of a potentially dangerous piece of code:

 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?

 Nowadays every self-respecting SAP developer should be aware of commonly known


vulnerabilities. “Awareness” may already remediate a lot of risks introduced through insecure
code, it surely does not close the gates for vulnerabilities getting introduced into your business
critical environment.

 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:

You might also like