Note: the information contained in this article is obsolete. For updated info, please read our Official Product Documentation here
ABAP applications programming -most of which are large customized systems- adds to the challenge of managing these large development projects, to ensure that the resulting code has the necessary quality and security, in order to avoid problems once in production, or excessive maintenance costs. The lack of verification or manual verification of the quality and security of these large systems is still a reality in about 40% of developers. Using Kiuwan Code Analysis helps reduce maintenance costs by up to 50%.
ABAP (Advanced Business Application Programming) is a fourth-generation language developed in the 1980s and created by SAP company. Originally used to develop the SAP R/3 platform, first released in 1992, it was also intended to be used by SAP customers to enhance SAP applications. Its syntax is similar to COBOL and is fairly easy to learn for programmers. In 1999, SAP released an object-oriented extension to ABAP called ABAP Objects, so object-oriented concepts are necessary to create ABAP programs. And, finally, it also requires knowledge of relational database design.
Code Quality & Security in ABAP
SAP Applications have moved from “isolated systems”, characterized by long release cycles, few attack vectors and companies security based on the use of firewalls, to the current “open systems”, with frequent release cycles, no network boundaries, cloud-based applications and hacker attacks. And for the next future they have to face high frequency releases, interconnected networks and cyber attacks.
Despite SAP has its own tool call Code Inspector for checking ABAP coding and DDIC objects under aspects of functional correctness, performance and statistical information, it has meaningful drawbacks that make it no suitable to be used by quality or security offices that have to lay down a holistic solution for all the languages in the customer application portfolios, or need to take into account other code analysis critical characteristics, like portability or security.
Surveys show that, at least, 40% of developers do not measure, monitor nor fix their code quality and security problems. Those who do it, increase their job’s delivery predictability in 9% and they also improve their application quality and security in 9%, reduce their maintenance costs up to 50%, or its technical debt till 90%.
Some warnings, errors or programming best practices should be obvious and generally valid for everybody, but they are not detected automatically by ABAP Development Environments and you may want to get help to know if the code you write or is written for you matches your organization code style, as well as your quality and security goals.
There are several kinds of tools that can help your development team, your quality and security office to do that, like Static Code Analysis Tools (SCA), Metrics, Dynamic Code Analysis, Profilers, Memory Tools or Monitoring Tools. Of these, the ones which provide more benefits are the SCA Tools.
Common issues when developing in ABAP
Talking with ABAP programmers and Project managers, they have exposed me several known problems, like:
- Team size and fluctuation, that lead to very heterogeneous knowledge and skill set.
- Maintenance, that gets harder with each iteration.
- There is too much code for manual review of coding guidelines.
- Complexity, that is too high for manual checks, because with code size, complexity grows exponentially.
- Code that looks locally ok, that can lead to problems when seen in its context and call hierarchy.
- Development teams ignarance about secure coding best practices.
In most cases, the main problem is that you do not know what your problems are until you analyze and measure your code.
We need to detect several types of issues, i.e. security flaws, code style, incompetent or inefficient code, concurrency and design issues, etc., although not everyone has the same consequences immediately.
For this post, let me focus on security flaws, where it is possible to found the kind of vulnerabilities that I am showing in the next paragraphs that have a very high impact:
Call transactions without check that current user has authorization
Without proper authorization checks, the program may allow an unauthorized user to start a restricted transaction.
Should we care about this? SAP was obviously aware of this security flaw and, in recent versions (7.4 and higher), they added WITH AUTHORITY-CHECK to CALL TRANSACTION command for explicit authorization check.
In 7.0 with enhancement package 3 (and higher), S_TCODE authorization object is checked in CALL TRANSACTION, so this vulnerability is especially useful for previous versions of ABAP.
This is a piece of code that violates this practice:
" VIOLATION: No explicit authorization check
CALL TRANSACTION 'SE38' USING BDCDATA MODE 'N' MESSAGES INTO MESSTAB.
" Starts ABAP editor, where attacker may inject or alter code in SAP system.
Use of Dynamic Code Constructs
ABAP Dynamic Code constructs are potential targets to code injection attacks, particularly when dynamic code generated could be affected by external inputs.
Such dynamic code constructs cannot be fully tested by QA team and leaves no trace, as code exists in memory (it is generated at runtime); it could be used to encode backdoors that may pass security audits.
This is a security defect APP-01 in BIZEC APP/11 standard.
As in the example below, these are several pieces of code that violates this practice:
* VIOLATION, creates subroutine pool from itabCode
GENERATE SUBROUTINE POOL itabCode NAME poolName.
* VIOLATION, generates program from code in reptab
INSERT REPORT lv_dynamic FROM reptab.
* VIOLATION, reads prog code into internal table itab
READ REPORT prog INTO itab.
* VIOLATION, for internal use only
GENERATE REPORT progname.
* VIOLATION, generates dynpro dynamically
GENERATE DYNPRO h f e m ID dynpro_id.
* Classical code injection attack when external input combined
* val is external input variable.
* Imagine attacker setting val = '3. DELETE FROM USR02'
FORM read_data USING val TYPE STRING.
" rep_append: append line of code to reptab internal table
rep_append 'REPORT ZREAD_DYNAMIC.'.
rep_append 'DATA: lv_val TYPE STRING.'.
CONCATENATE 'lv_val = ' val '.' into l_statement.
INSERT REPORT lv_dynamic FROM reptab. " VIOLATION
SUBMIT (lv_dynamic) AND RETURN. " dynamic code executed
* Code executed could be this, if val is '3. DELETE FROM USR02'
* REPORT ZREAD_DYNAMIC.
* DATA: lv_val TYPE STRING.
* lv_val = 3. DELETE FROM USR02.
<strong style="color: inherit; font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 24px; background-color: #ffffff;">Kiuwan and ABAP</strong>
Kiuwan Code Analysis helps us avoid these pitfalls.
Only for ABAP, it brings more than 230 rules. Among others, Kiuwan has these rules to detect the common mistakes with exceptions showed above:
- Authorization check must be done explicitly before CALL.
- Avoid Dynamic Code constructs.
First, I check if I have the rules capable to detect the above vulnerabilities in my Quality and Security Model:
The details of the rules can be found in the rules library, where you can consult examples of right code that solves the founded vulnerabilities.
Then, by analyzing the code, I get these results (among many other metrics, indicators, reports, etc.) in Kiuwan’s Summary:
And these other detail result in Kiuwan Defects Dashboard:
If we have the time that Kiuwan suggests us in order to fix theses vulnerabilities, we can see the effect once we do it.
Kiuwan has an interesting feature to quantify our progress, comparing some of its indicators:
If you are interested in a more detailed guide, we reccomend you download our free ebook Bulletproofing your SAP ABAP applications