SQL Injection 

Description

Today all Web applications are accessed using the Internet and therefore face the risk of being exposed to manipulation. Most of the Web applications rely on Relational Database Management System (RDBMS) servers, which represent a possible vulnerability to SQL injection attacks arising from direct integration of user input into SQL statements without appropriate validation or filtering.

The basis of this vulnerability lies in the creation of SQL commands with character strings. Attackers are successful if they are able to change the semantics of an SQL statement for their benefit or are able to insert their own statements into the application. Entry points can be, for example, input boxes in Web forms or URLs. The results could be unauthorized information access, information disclosure, unauthorized data modification, or data loss.

SQL Injection Attack Categories

SQL Manipulation

SQL manipulation can take place as follows:

●     Using the operation UNION.

●     Changing the WHERE clause.

Examples

Example Code 1

Original SQL Statement

SELECT fieldlist    FROM table1 WHERE field = 'userinput'.

Example of an SQL Injection Attack

SELECT fieldlist    FROM table1 WHERE field = 'UNION ALL SELECT other_field                 FROM other_table WHERE '='.

Example Code 2

Original SQL Statement

SELECT fieldlist    FROM table WHERE field = 'userinput'.

Examples of an SQL Injection Attack

SELECT fieldlist    FROM table WHERE field = 'anything' OR 'x'='x''.  SELECT fieldlist    FROM table WHERE field = 'x' AND email IS NUL; --'.

Code Injection

Code injection can take place as follows:

●     Inserting new database commands into the vulnerable code.

●     Appending an SQL server EXECUTE command to the malicious code.

Examples

Example Code 1

Original SQL Statement

SELECT *    FROM table WHERE name = 'userinput'.

Example of an SQL Injection Attack:

SELECT *    FROM table WHERE name = ' a'; DROP TABLE users;               SELECT *                 FROM  table1               WHERE name = '%''.

Functional Call Injection

Functional call injection is the insertion of various database function calls into a vulnerable SQL code.

Several known attack strings listed in the table below may be a part of the SQL injection code to manipulate the original query. Hackers try various input combinations to force SQL statements into an error message. The following list of malicious inputs may or may not give the same results depending on the server. Therefore, try all the inputs.

Possible Attack Strings

‘	Badvalue’	‘ OR ‘	‘ OR	;	9,9,9
...; SELECT	^\n	exec()
' or 0=0 --	" or 0=0 --	or 0=0 --	' or 0=0 #	" or 0=0 #	or 0=0 #
' or 'x'='x	" or "x"="x	') or ('x'='x	' or 1=1--	" or 1=1--	or 1=1--
" or "a"="a	') or ('a'='a	") or ("a"="a	hi" or "a"="a	hi" or 1=1 --	hi' or 1=1 --

You need to take into account the different output of possible vulnerable metacharacters in SQL statements. Characters could be displayed as ASCII, HEX, escaped ASCII, and escaped HEX. These four potential notations reveal the complexity of SQL injection attacks of this type.

Possible Characters to be Used in SQL Code Injection

ASCII	HEX
SPACE	%20
\SPACE	\%20
\'	\%27
'	%27
\"	\%22
"	%22
--	%2D%2D
\-\-	\%2D\%2D
\=	\%3D
=	%3D
\;	\%3B
;	%3B
\#	\%23
#	%23

Examples of Combinations of ASCII and HEX-Characters Used Within Malicious Code

ASCII / HEX-characters	Explanation
\w*	Zero or more alphanumeric or underscore characters.
(\%27)|\'	The ubiquitous single-quote or its hex equivalent.
(\%6F)|o|(\%4F))((\%72)|r|(\%52)	The word 'or' with various combinations of its upper and lower case hex equivalents.
((\%2F)|\/)*	The forward slash for a closing tag or its hex equivalent.
[a-z0-9\%]+	The alphanumeric string inside the tag, or hex representation of these.
(\%3C)|<)	The opening angled bracket or hex equivalent.
((\%3E)|>)	The closing angled bracket or hex equivalent
(\%69)|i|(\%49))((\%6D)|m| (\%4D))((\%67)|g|(\%47)	The letters 'img' in varying combinations of ASCII, or upper or lower case hex equivalents.

What Do I Get from the SAP NetWeaver Platform?

...

       1.      Open SQL for ABAP provides some implicit protection against SQL code injection as follows:

○     Since all statements are prepared, it is not possible to insert malicious code snippets using host variables, as, for example the comparison values of a WHERE clause.

○     The SQL statements SELECT, MODIFY, UPDATE, INSERT, and DELETE may all have dynamic clauses. But:

■      The leading keyword of a clause has to be static.

■      No SQL statement can be executed within a clause of another statement completely dynamically.

■      Sub-queries can contain dynamic clauses but the leading SELECT keyword is always static.

       2.      Native SQL for ABAP is always static from the ABAP language point of view. There are no dynamic Native SQL statements at all.

○     Due to its static nature, a source code scan may be done:

■      For the following fields, such as MANDT or CLIENT

■      For the statement EXECUTE PROCEDURE.

Regarding both ABAP-based SQL language concepts described above, see the recommendations explained in the sections What Do I Need to Do? and How Not to Do It? to prevent SQL injection attacks.

What Do I Need to Do?

As mentioned above, the information in Relational Database Management Systems is stored and retrieved with SQL statements. Therefore the following general rules may be helpful to circumvent SQL injection attacks:

●     Define a codepage (such as charset = ISO-8859-1) to clearly decide which characters are problematic.

●     Filter user input while retrieving user information for your SQL statement.

●     Filter your data with the following regular expression for numbers and letters.

○     s/[^0-9a-zA-z]//g

●     If the user is allowed to submit an email address, allow only “@”, “_”, “.” and “-“.

●     Enclose all user input in quotation marks, even if it is numerical.

●     Restrict the rights of the Web application user.

●     Configure error reporting.

○     Restrict error reporting (by server-side and by application) so that internal system information cannot be shown to outside users. If the full query is shown, pointing to the syntax error involved, this assists hackers in mounting Cross-Site Scripting (XSS) attacks.

●     Use the ABAP addition ‘CLIENT SPECIFIED’ in a restrictive way, for example, for client copy.

●     Restrict the dynamic program generation performed with the ABAP key words to filtered user input only:

○     INSERT REPORT

○     GENERATE SUBROUTINE POOL

How Not to Do It?

Never include any coding like the following, unless you take full control of the content of the dynamic clauses:

SELECT  (select_clause)    FROM  (from_clause) CLIENT SPECIFIED INTO <fs>    WHERE (where_clause)    GROUP BY (groupby_clause) HAVING (having_clause)    ORDER BY (orderby_clause).

Otherwise, if a developer allows unfiltered user input values to be taken for such a SELECT statement, any attack may be possible with which almost the whole database could be read.