ABAP code security : What to do in 2016 ?
After reading the Top 10 ABAP crimes — which is a great resource for anyone who writes ABAP code —
I would like to add some security specific hints.
Since we all want our business critical software to run securely we need to avoid among others
some common implementation security bugs such as SQL injection or path traversal.
To catch these, SAP developed the so-called NetWeaver Add-on for Code Vulnerability Analysis (CVA),
for developers (in- and ) outside SAP. CVA has been available since 2013 with regular feature enhancements.
Today there are in excess of 50 different CVA checks.
With the recent version you can also use CVA to check developments in older basis releases (SAP_BASIS > = 7.00 )
The checks will highlight potential implementation bugs – the results are integrated directly in the ABAP Test Cockpit
CVA provides comprehensive guidance and fix recommendations for each finding allowing you to make the final choice.
Additionally, some guideline you may find helpful – Secure Programming – ABAP.
If you would like to know more I recommend to read this book (from my colleagues Thorsten Dunz and others – currently in German only):
Besseres ABAP: Schnell, sicher, robust – … (SAP PRESS, link is to Amazon.de )
Below you find a description of the CVA security checks grouped by type.
Inspired by the OWASP Top 10 security weaknesses from 2013 we can combine the
available CVA checks in the following groups:
This threat and its mitigation are well described in the ABAP secure programming guide section SQL Injections .
Correction instructions can be found in the online documentation for findings.
For example the following vulnerability patterns are checked by CVA (among many others) :
|SQL Injection for dynamic WHERE clause||
UPDATE dtab.. WHERE (iv_where).
DELETE dtab WHERE (iv_where).
ABAP Code Injections
ABAP has some powerful statements allowing to dynamically generate and execute code.
The statements are INSERT REPORT and GENERATE SUBROUTINE-POOL.
CVA checks if user input is used to insert the coding to be generated.
There are some good recommendations in Horst Keller’s ABAP programming guidelines.
OS Command Injections
The ABAP – Keyword Documentation describes this vulnerability pattern as follows:
A system command injection is an attack method that can result from insufficiently secure input from outside. A System Command Injection forwards malicious operating system statements, which enter a program from an external source, to the operating system. In ABAP, this can occur when the following programming techniques are used:
- On the application server
- Input forwarded from an external source to the parameters of the function modules used to call operating system statements using the SXPG framework
- When the addition FILTER of the statement OPEN DATASET is used and some or all of the specified operating system statement originates from outside the program.
- Using the internal statement CALL for the special system function SYSTEM if part of the specified operating system statement or some or all of its parameters come from outside the program.
- On the presentation server
- Input forwarded from an external source to the parameters of the method, the class, or the function module .
CVA checks will highlight potential OS command injections.
Mitigation is mostly avoiding CALL ’SYSTEM’ or CALL cfunc, or in case absolutely necessary replacing by the SXPG framework.
Cross-Site Scripting (XSS)
XSS is the name of a class of security vulnerabilities that can occur in Web applications.
The threat and its mitigation are reasonably well described in Secure Programming: Cross-Site Scripting
This vulnerability type is also checked for Business Server Pages (BSP’s).
Since BSP’s are not pure ABAP coding, you can call the checks out of BSP maintenance (SE80)
using the option Check using ABAP Test Cockpit (do not forget to switch on the flag Security Check for BSP )
Remark – In addition to all the standard ABAP vulnerability patterns, CVA can also check BSPs for obsolete design, missing XSRF protection, potential unvalidated URL redirect or use of obsolete escape methods.
Insufficient protection against directory traversal attacks
Conceptually it is a consequence of insufficient input validation.
This threat and its mitigation are well described in the ABAP secure programming guide section DirectoryTraversal.
The ABAP application server provides standard mitigation methods such as using Logical File Names.
Backdoors (see OWASP definition) are a somewhat fuzzy vulnerability type – all ABAP code that can be used
to intentionally modify program flow, for example to bypass authorization checks, would fall in this category.
CVA checks for hardcoded usernames, passwords, system IDs, clients and system variables check against hard-coded values.
Note, any dynamic coding influenced by user input could be used as backdoor – and is being checked by CVA
as Code Injection.
Missing or incorrect authorization checks
In ABAP systems authorizations are checked both implicitly (for example before starting a transaction) and at program level
using the statement AUTHORITY-CHECK.
When doing own developments you may need Programming own Authorization Checks.
CVA can help you to find missing authority-checks in reports or remote-enabled function modules (aka RFC’s ) or before statement CALL TRANSACTION.
Language enhancements allow you to use statement CALL TRANSACTION with addition WITH AUTHORITY-CHECK or WITHOUT AUTHORITY-CHECK to suit your business scenario.
It also check against such a simple, but nasty implementation bug as SY-SUBRC not evaluated after
statement AUTHORITY-CHECK or other critical functions performing authorization checks (customizable).
Additional useful reading:
- Securing Remote Function Calls (RFC) is a very important topic if you want to harden an ABAP system – the paper from my colleague Christian Wippermann describes the concept, tools and approach how to succeed.
- ABAP keyword documentation (link to version 7.40)