Security of ABAP programs is an important subject. In this blog I try to drill it down to some basic facts. This blog is for responsible developers who want to protect their ABAP code against attacks.
As a responsible developer you must prevent mainly two security risks:
o SQL Injections
Input from the outside is directly used in dynamic tokens of Open SQL or in statements passed to ADBC.
o Dynamic Calls:
Input from the outside is directly used in statements that call programs or procedures.
o Directory Traversal
Input from the outside is directly used in statements of the ABAP file interface.
o System Command Injections
Input from the outside is directly used as system commnad, .e.g. behind CALL 'SYSTEM'.
o Cross Site Scripting
Input from the outside is directly used in HTML files for web pages.
o ABAP Command Injections
Input from the outside is directly used in generated ABAP code.
As a rule, you should restrict dynamic code that involves input from outside the program to the absolute necessary. If you have to work with that dangerous kind of code, the methods of class CL_ABAP_DYN_PRG and also the built-in function escape help you to check and escape input from the outside before using it in statements. Check tools for static code analysis can help in finding such positions.
Typical example: You must apply CL_ABAP_DYN_PRG=>ESCAPE_QUOTES to any input that you want to concatenate into a dynamic WHERE clause to prevent access to forbidden data:
PARAMETERS name TYPE string.
DATA cond type string.
cond = `country = 'DE' AND name = '` &&
cl_abap_dyn_prg=>escape_quotes( name ) && `'`.
SELECT * FROM scustom
INTO TABLE customers
WHERE (cond).
Without escaping, an input like x' OR name <> ' would select all data from SCUSTOM.
As a responsible ABAP programmer, you pay attention to these points and try to secure your code by checking authority and controlling any input from the outside. Malicious ABAP programmers do it another way around. They build back doors and try to obscure them. For example, if you find code, where the system field sy-uname is dynamically assigned to a field symbol and where this field symbol is then used to control the program flow, you might have found a back door where someone tried to obscure an user dependent program execution. The problem is, that a malicious programmer might always find a way to outwit a check tool. Therefore only code inspections or team programming might prevent such back doors.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
5 | |
3 | |
3 | |
3 | |
2 | |
2 | |
2 | |
2 | |
1 |