SAP security is a great challenge and will be a challenge for many years to come. In order to thoroughly secure an SAP application, all of its components (i.e. SAP HANA) and potential threats need to be understood. SAP security is multi-layered, its building blocks range from infrastructure all the way up to SAP application security. In order to break an application, only one flaw may be sufficient in order to compromise an entire environment.
Below you can find an overview of all SAP security notes released since 2010, categorized by their vulnerability type. Majority of all vulnerabilities find their origin within insecure ABAP developments. Within this blog article, we will in particular zoom in on SQL-injection.
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 can extract the entire user master!
The code above may be a textbook example, and 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 than 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 allows 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 Analyser (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 comes at a very steep license cost.
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.
As there is no instant alerting possible we investigated for ways to identify code vulnerabilities when the vulnerability is being introduced, at code writing or code activation.
Real-time code vulnerability checks
Using the SecurityBridge framework, which is a real-time threat- and vulnerability monitoring tool, a number of very specific ABAP vulnerability listeners have been made available.
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 business-critical operations. However, when a developer gets an instant alert while still coding no unnoticed vulnerabilities will be released into subsequent environments.
measurement drives performance!
Back to our example
Let us look at the example used in the very beginning. Once we generate program z_open_sql_example_01 the program generation is identified by an intrusion detection scanner, which continuously guards the system.
Within minutes following email alert reaches your inbox:
Upon receipt of this email, I would immediately adjust the code to mitigate the vulnerability, introducing e.g. methods of class CL_ABAP_DYN_PRG which prevent the program from accepting SQL-injections.
The setup at a glance
Within this post we shall not talk about SecurityBridge itself, this goes far beyond the topic of ABAP code vulnerability. In here we only look at one specific “listener”, a component designed to complement existing tools like SAP-CVA.
Once the ABAP Code Vulnerability listener is activated the intrusion detection scanner ensure your system(s) are guarded. Per vulnerability type, we can also assign a severity which can be used in order to trigger specific actions.
You may want to use event statistics in order to verify how vulnerabilities within your code base evolve over time. As shown in the example above, internally at ABAP-Experts, we trigger an email alert which goes to the developer as an extra reminder.
When a new vulnerability, however, gets introduced into a productive instance system, system governance or your security operations center may want to be involved.
Now, are you monitoring your code?