Expand +



Start Your ABAP Applications on Solid Ground

Minimize Source Code Risks with SAP NetWeaver Application Server, Add-On for Code Vulnerability Analysis

by Patrick Hildenbrand | SAPinsider, Security-Strategies, Volume 14, Issue 4

October 1, 2013

SAP provides customers a number of tools and checks for securing their systems. Recently, it expanded its security offerings by unveiling a product that had only been used internally at SAP: SAP NetWeaver Application Server, add-on for code vulnerability analysis. Learn how the tool efficiently scans ABAP source code to search for any potential security vulnerabilities in your applications.


Today’s business applications are often complex programs built over a number of years to help companies run as efficiently as possible. Organizations often pay a great deal of attention to fine-tuning these applications for performance, but even the highest levels of performance cannot protect the sensitive assets hosted by these applications. Securing data is not only in the interest of that data’s business owners — for example, it is critical to HR’s purposes to secure HR data — but is also necessary to meet legal requirements and industry standards.

Cryptography, authentication, and authorizations are fundamental parts of protecting your data assets, but even more important is ensuring that the code that is driving your applications executes correctly and efficiently without opening up opportunities for attackers. SAP ensures the security of its own application code by following a standard set of test procedures that include an integrated set of static and dynamic security checks and manual reviews. To help its customers follow the same approach to ensure the security of their own applications, SAP provides a comprehensive, integrated framework of testing tools and checks as a part of SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP.1

While the standard tools and checks that SAP provides for customers cover a wide range of the testing needed to ensure application security, an integrated tool for efficiently scanning ABAP source code for security vulnerabilities has not been available — until now. SAP now offers to customers the tool it uses internally to scan its own ABAP source code for security risks: SAP NetWeaver AS, add-on for code vulnerability analysis.

Testing Approaches for Building Application Security

Application security is usually evaluated using a dynamic application security testing (DAST) approach, a static application security testing (SAST) approach, or some combination of the two.

DAST is an outside-in approach, in which you look for potential vulnerabilities in the installed, running application using automated or semi-automated tools. The expertise needed for a DAST approach is less about the programming language and more about the abilities of the engines used and how to trigger vulnerabilities in the application. While a DAST approach enables you to reveal potential risks in an application, it can only identify these risks once the application is up and running, and after the resources have been expended to build it.

SAST is an inside-out approach that uses automated or semi-automated tools to scan the source code of the application and identify potential security issues during development, before the application is fully built. This approach can help developers avoid security pitfalls at the time they create the source code. While the SAST approach can find vulnerabilities much earlier than the DAST approach, it cannot identify the potential for insecure use of a system — for example, an insufficiently validated file reference in an application, which can expose files anywhere on the application server to a directory traversal attack.

In many cases, it makes sense to use both DAST and SAST checks for an application. Let’s say that an application uses a function that allows files to be uploaded to a directory on the application server. With SAP NetWeaver Application Server ABAP, the application can call the FILE_VALIDATE_NAME function module to check whether the upload points to a permitted directory. A SAST check can verify that there is an interface to perform the upload and that the validation function is used to ensure that the destination directory is permitted. However, it cannot identify whether the destination directory should be permitted in the first place — that is, as long as the validation function is used, no warning is raised, even if the permitted directory opens the server to a directory traversal attack (for instance, if the permitted directory is the root directory of a Unix system, which would allow access to the entire system, or the /etc/passwd directory, which would allow an intruder to change the security configuration of the system). In this case, in addition to using a SAST check to ensure that the proper pieces are in place in the source code, you would want to use a DAST check to reveal any insecure accesses that the code may be permitting.

Regardless of the testing approach, some kind of manual review is always required, because even the savviest automated testing tools cannot understand the intentions of an application. For example, think of an entry page for money transfers. Let’s say an intruder has coded every 10th transfer to go to his or her bank account instead of the account entered in the user interface. Automated tools understand only insecure coding — so as long as the transfers are coded securely, the tools will raise no flags. To understand this as illegal coding with ill intentions, a manual, human interpretation of the requested business function is required.

Eliminating Exposure at the Source

SAP NetWeaver AS, add-on for code vulnerability analysis scans ABAP source code for the critical flaws identified by the Open Web Application Security Project (OWASP) for 20132 (see Figure 1). In particular, it focuses on:

  • Injection attacks (A1), such as SQL, OS, or code injections
  • Insecure direct object references (A4), such as directory traversal attacks
  • Missing access control (A7)
  • Insecure use of SAP NetWeaver AS ABAP functions (A9)
A1 Injection
A2 Broken authentication and session management 
A3 Cross-site scripting (XSS) 
A4 Insecure direct object references 
A5 Security misconfiguration 
A6 Sensitive data exposure 
A7 Missing function-level access control 
A8 Cross-site request forgery (CSRF) 
A9 Using components with known vulnerabilities 
A10 Unvalidated redirects and forwards 

Figure 1 Top 10 web application security flaws for 2013 identified by the Open Web Application Security Project (OWASP)

The security checks of SAP NetWeaver AS, add-on for code vulnerability analysis are more precise than the standard checks included with SAP NetWeaver AS ABAP because they are able to use information about the application’s internal data flow — such as how data entered into a field in a user interface is used within an ABAP statement — to identify risks. In addition, the security checks do not show warnings or errors when they detect coded security precautions, such as sanitizations or secure sources of data, thereby increasing efficiency by avoiding time wasted on false alarms. Instead, the search focuses on places in the code where input from outside of the code unit is used in a statement, which is known to be a potentially insecure location within the code.

How It Works

SAP NetWeaver AS, add-on for code vulnerability analysis is tightly integrated into the existing test infrastructure of SAP NetWeaver AS ABAP. This infrastructure is based on the Code Inspector, which is a test framework that comprises a variety of development checks and functions for evaluating code elements such as syntax, performance, security, and reliability. Although SAP NetWeaver AS, add-on for code vulnerability analysis can be used standalone, SAP recommends using it via the ABAP Test Cockpit. (See the sidebar for more on the ABAP Test Cockpit.)

The ABAP Test Cockpit

The ABAP Test Cockpit is a standard ABAP check tool, included with the Code Inspector testing framework. It enables the execution of static checks and unit tests — including the extended security checks of SAP NetWeaver Application Server, add-on for code vulnerability analysis — for your ABAP development objects. The ABAP Test Cockpit integrates tests written for the Code Inspector to enable the reuse of existing checks and check variants. It is directly integrated into the ABAP Workbench as well as the ABAP development tools for Eclipse, and enables developers to check code from within their familiar development environment.

Working with the ABAP Test Cockpit as a developer is easy and efficient with the new ABAP Test Cockpit filter, navigation, and recheck functionalities. Team leads and quality engineers will also find added value in the ABAP Test Cockpit because it introduces new quality assurance processes such as quality gates, a robust exemption approval process, email notifications about errors and exemption workflow events, and periodic regression tests in a quality system. More details on the ABAP Test Cockpit are available at

You enable the extended security checks of SAP NetWeaver AS, add-on for code vulnerability analysis in your SAP NetWeaver AS ABAP system using the program RSLIN_SEC_LICENSE_SETUP. Once enabled, it is recommended that you adapt the default check variant for the ABAP Test Cockpit to contain the extended security checks, so that they are automatically included when you run the analysis. This is done in the Code Inspector (transaction SCI) by enabling the option “Security Analyses in Extended Program Check” (see Figure 2).

Figure 2 Enabling the extended security checks in the Code Inspector

Now a developer can launch the extended security checks directly from within the developer environment, including the ABAP Workbench as well as the ABAP development tools for Eclipse. In the ABAP Editor (transaction SE38), for instance, the developer can launch the checks for a program, function, class, or package by simply right-clicking on the desired object and selecting Check > ABAP Test Cockpit (see Figure 3). The ABAP Test Cockpit will then run the checks and present the results in a flexible list that allows for grouping or filtering of entries.

Figure 3 Running the extended security checks using the ABAP Test Cockpit


Example Scenario: Identifying and Securing a Vulnerability

Let’s see what it looks like when the ABAP Test Cockpit tool identifies a risk after running the extended security checks of SAP NetWeaver AS, add-on for code vulnerability analysis, and what kind of support is available to help developers address any identified issues.

Identifying a Vulnerability

Figure 4 shows the source code for a simple self-service application that allows users to maintain addresses (street name, ZIP code, and city name) within the SAP NetWeaver AS ABAP system.

Figure 4 Source code for a simple self-service application for maintaining addresses


SAP NetWeaver AS, add-on for code vulnerability analysis is a separately licensed product. Availability is planned for September 2013 with compatibility with:

  • SAP NetWeaver AS ABAP 7.0, enhancement package 2, support package 14
  • SAP NetWeaver AS ABAP 7.0, enhancement package 3, support package 09
  • SAP NetWeaver AS ABAP 7.3, enhancement package 1, support package 09
  • SAP NetWeaver AS ABAP 7.4, support package 05 and later releases

The extended security checks will not only look for a specific statement — such as an ABAP “update” statement — to raise a security message, but will also look for statements used in an insecure fashion (for example, statements that allow unsecured user input). In the example in Figure 4, the ABAP statement UPDATE (line 21) could be potentially misused, as it uses a dynamic SET condition. The dynamic part of an ABAP statement is usually written with an identifier (a variable name) enclosed by parentheses; in the example, (set_expr) in line 22. This code will lead to set_expr being evaluated by the ABAP interpreter during the runtime of the program and then executed by the ABAP application server. Assuming there is a field with the name salary, a correct set expression would look like:

STREET = 'xyz' salary = '1500'

In general, a dynamic statement is not always a risk. It becomes a risk if it allows the user of the program to exploit the data within the set_expr variable. To identify such risks, the extended security checks search for user input (in the example, the PARAMETERS statement in line 3) that is used in a potentially dangerous statement (the UPDATE statement in line 21) either directly or indirectly (in the example, it is used indirectly as part of the dynamic statement). The extended security checks recognize the data flow of the parameter street (declared in line 3) and the assignment to the set_expr (line 10), and will raise a security finding for this code (in this case, the vulnerability is a possible SQL injection). The data flow is presented in the ABAP Test Cockpit message (see Figure 5), allowing the developer to understand the data flow from the source to the dangerous statement.

Figure 5 The ABAP Test Cockpit displays the results of the extended security checks


User input could reach a potentially dangerous statement from a variety of channels. A PARAMETER statement is only one example of such sources; others could be the interface of a remote function module or database tables in which the user can create or change data. Depending on the data type, not all of these input channels are considered exploitable for possible attackers. To avoid false warning messages, the extended security checks also consider the structure of the data. For example, it’s very difficult for an attacker to exploit a set_expr that allows the user to enter only integers, so in the case of the example, the checks would not identify the set_expr for the ZIP code (line 13) as a vulnerability.

Securing a Vulnerability

Once the extended security checks identify a risk, how does a developer go about fixing it? Detailed online documentation is provided for the ABAP developer for each security check performed by the ABAP Test Cockpit. To access the documentation, the developer clicks on the message displayed in the ABAP Test Cockpit (refer back to Figure 5).

The documentation explains the risk that has been identified for the example scenario (see Figure 6), and provides advice on how the code should be changed to ensure proper, secure use of the program. It also describes the used procedure of the security checks, so that the developer can understand why the checks are reporting an issue.

Figure 6 Online documentation provides the developer with information about the identified vulnerability and how to address it


Using the information from the online documentation, the developer can adapt the code, as shown in Figure 7. For the example, adding a quote function in lines 10 and 16 securely encodes the parameters. Because the ZIP code in this example is an integer field, which means that an attacker cannot exploit this field in the way a free-text field can be exploited, the encoding function is not necessary for the zipcode parameter.

Figure 7 Source code for the self-service application with vulnerabilities addressed in the street and city parameters


With these changes in place, the security checks will no longer raise an error message for this code.


Your valuable data assets are only as secure as the applications that host and access them. SAP is committed to providing its customers with the same high-quality checks and testing capabilities it trusts to secure its own software, as well as the guidance customers need to put in place a secure approach to coding applications for SAP NetWeaver AS ABAP.3 With the release of SAP NetWeaver AS, add-on for code vulnerability analysis, SAP brings to its customers the powerful scanning functionality it has used for years to identify vulnerabilities in the source code of its own applications, and it has already been piloted in a recent customer engagement initiative with much success. Backed by the knowledge of the team that develops the ABAP language, SAP NetWeaver AS, add-on for code vulnerability analysis enables you to easily and efficiently locate security risks in your code, so you can create secure applications with confidence.

To learn more, visit and



1 The white paper “Secure Software Development at SAP” — available at — describes SAP’s efforts to ensure secure applications. SAP Note 1697494 (Customer Code Scans) — available at — details SAP’s recommendation that customers perform code scans for their own development work.

2 For more on the top 10 security flaws identified by OWASP for 2013, see

3 The secure programming guide for ABAP provides extensive documentation on how customers can achieve a high level of security for their applications on SAP NetWeaver Application Server ABAP. The guide is available at


An email has been sent to:


Patrick Hildenbrand
Patrick Hildenbrand

Patrick Hildenbrand ( has been working in the security space since 1994. Since 2013 he has been a Product Manager for Security at SAP AG. His focuses include authentication, access logging and source code security, and the SAP NetWeaver AS J2EE Engine.

More from SAPinsider


Please log in to post a comment.