ABAP Code Vulnerabilities, a call for real-time security alerts

ABAP code vulnerabilities

SAP security is a great challenge and will be a challenge for many years to come. In order to thoroughly secure an application, all of its components and potential threats need to be understood. SAP security is multi-layered, its building blocks range from infrastructure to application security. In order to break an application, only one flaw may be sufficient to compromise an entire environment.

Below an overview of SAP security notes released between June and November 2017, categorized by their priority.

A good number of vulnerabilities find their origin within insecure ABAP coding. Within this blog article we will in particular zoom in on SQL-injection, one of just many ABAP code vulnerabilities.

By reading this blog post, the first one in a series, I want to trigger the awareness for the need of real-time security monitoring.

What is SQL-injection?

In ABAP we have various ways of reading and updating database values. By modifying specific variables or SQL-access clauses one can gain unauthorized access to secured data, or one can even alter data directly on the database.

Let’s look at the most basic form of SQL-injection through the use of commonly used open-SQL statements and a selection-screen parameter.

Following program reads user master data for a specific user-ID:

When we run the report “as designed” we get the output for one particular user.

When we however fiddle around with the input entered at the selection-screen, perfectly bypassing typical validation rules, we are able to extract the entire user master!

The code above may be a textbook example, you may be surprised how often we see such code snippets passing through established QA processes. And to be truly honest, being an ABAP developer myself for more then 20 years, also I have to plead guilty when it comes to introducing certain unwanted vulnerabilities.

Besides relatively basic SQL-injection scenarios, using Open-SQL, new technologies also introduce new vulnerabilities. An example here being ABAP managed database procedures, the SQL-scripting functions available within HANA databases. EXEC-statements using variables parts impose a very similar risk as seen with Open-SQL.

How to identify SQL-injection vulnerabilities?

Nowadays every self-respecting SAP developer should be aware of commonly known vulnerabilities. “Awareness” may already remediate a lot of risks introduced through insecure code, it surely does not close the gates for vulnerabilities getting introduced into your business critical environment.

SAP standard offers a range of tools in order to ensure code violations can be identified. The ABAP Test Cockpit (ATC) is an ABAP check framework which allow static checks and unit tests for ABAP programs. ATC is also the umbrella above SAP Code Inspector (SCI), the extended syntax check (SLIN) and the SAP Code Vulnerability Analyzer (CVA).

Especially this last one, the SAP code vulnerability analyzer, serves a great purpose when it comes to code security. Although SAP ships CVA as standard with recent NetWeaver releases its use unfortunately is far from free.

Code security should not be optional

Especially within large enterprises we see the awareness of risks and vulnerabilities translate into very concrete measures to mitigate the ever growing risks of hacking, data theft, data loss, …

Next to the SAP standard portfolio of tools like code inspector and CVA there are a number of –excellent– 3rd party tools on the market which perform static code scans, even offering instant remediation options. Still such tools highlight vulnerabilities at a relatively late stage.

Code verification might be executed by the developer, or during a peer or QA review at transport release. At best, a static and overall analysis is executed once sources are released or even productively deployed.

Security often starts with code, without code there would be no vulnerabilities.

Quality of the code base has a direct relation to vulnerabilities

Real-time code vulnerability checks

Whenever a developer introduces a fresh vulnerability within a development environment this may be of no relevance (yet) for your security operations center, they may mainly monitor your productive and critical business  operations. However, when a developer gets an instant alert while still coding no unnoticed vulnerabilities will be released into subsequent environments.