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 in order to compromise an entire environment. In the SAP security notes released in January 2017, a good number of 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 usermaster 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 identifed. The Abap Test Cockpit (ATC) is a check framework which allow static checks and unit tests for Abap programs.
ATC is also the umbrella above SAP Code Inspector (SCI), the extended synax 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.
Abap 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, etc.
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.
When it comes to code QA: measurement drives performance!
Back To Our Example
Let’s 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. Additionally, within minutes, an email alert reaches my inbox.
Upon receipt of this email I would immediately adjust the code to mitigate the vulnerability, introducing 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 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 governance or your security operations center may want to be involved.
Now, are you monitoring your code ?
Add Comment