SAP R/3 форум ABAP консультантов

[admin]

SAP NetWeaver Developer’s Guide Release: SAP NetWeaver 2004s
Secure Programming – ABAP - https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/17a4f828-0b01-0010-8da1-d18bb60ec2bf

SQL Injection
Description
Today all Web applications are accessed by Internet and so face the risk of being exposed to manipulation. Most of the Web applications rely on RDBMS (Relational Database Management System) servers representing 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 benefits or are able to insert own statements into the application. Entry points can be for instance input boxes in Web forms or URLs. The results could be unauthorized information access, information disclosure, unauthorized data modification or data loss.
Several main categories of SQL injection attacks are distinguished:

SQL Manipulation:
• Using the operation UNION.
• Changing the WHERE clause.

Example Code 1:

Original SQL statement:
SELECT fieldlist
FROM table1
WHERE field = 'userinput'.

Examples for 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 for 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:
• Inserting new database commands into the vulnerable code.
• Append a SQL server EXECUTE command to the malicious code.

Example Code 1:
Original SQL statement:
SELECT *
FROM table
WHERE name = 'userinput'.

Examples for SQL injection attack:
SELECT *
FROM table
WHERE name = ' a'; DROP TABLE users; SELECT * FROM table1 WHERE name = '%''.

Functional Call Injection:
• 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 enforce 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, it will be good to try all the inputs.
Possible attack strings are:
‘
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 --

Attention has to be paid to 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 such SQL injection attacks.

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 for 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 angle 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 already offers some implicit protection against SQL code injection as follows:

Since all statements are being 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, e.g. MANDT or CLIENT and
• for the statement EXECUTE PROCEDURE.
Regarding both ABAP-based SQL language concepts described above, please refer to the recommendations as explained in the sections “What Do I Need to Do?” and “How Not to Do It?” in order 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 (e.g. charset = ISO-8859-1) to clearly decide which characters are problematic.
Do 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 “-“.
Prepend and append a quote to all user input, even if it is numeric.
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. For hackers Cross-Site scripting (XSS) attacks are facilitated, if the full query is shown, pointing to the syntax error involved.

Use the ABAP addition ‘CLIENT SPECIFIED’ in a restrictive way, e.g. for client copy.
Restrict the dynamic program generation done with the ABAP key words
• INSERT REPORT
• GENERATE SUBROUTINE POOL
to filtered user input only.
How Not to Do It?
Never include any coding like the following, unless you take full control over 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 to read almost the whole database.