Skip to Content

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.

In a next post we will talk about ABAP code injection. Can’t wait? Join me at the Cybersecurity conference for SAP customers 2017.

 

Now, are you continuously checking your code base for vulnerabilities?

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Joachim Rees

    Hey Ivan
    (your first- and last name got mixed up here, right?),

    congrats on your first SAP Community blog!

     

    Just pointing out the obvious:

    You can tell the example is constructed to explain you point.

    A “cleaner” version of that program would

    1. Not do an array-fetch, when it only should retrieve a single record.
    2. Not used a dynamic but a static condition (where BNAME eq p_user)

     

    I do see the need to have easy to understand examples, but I’m wondering if you maybe also can show us a real-live example?

    best

    Joachim

     

    (0) 

Leave a Reply