ABAP and security - it's all about authorizations, isn't it?

[Michael_Keller]

Dear community, some time ago I had a good talk with codehorse who is a security specialist for SAP software. Our topic was ABAP and security.

What perhaps everyone thinks of when it comes to this topic: authorization checks. To be honest: For me, security in the ABAP environment primarily meant the security of SAP NetWeaver ABAP stack. So more from the point of view of system administration (patches, etc.). In part, I also understood security in the context of clean code, i.e. whether an application is maintainable. And not to forget: authorization checks 😉

In our talk Marco said that there are more security issues related to ABAP. Whether intentional or not, you can strengthen or weaken the security of the system or the respective application through your ABAP programming. It wouldn't just be about forgotten authorization checks.

That sparked my interest in the subject. I like to learn from other disciplines. In general: In recent years, many important impulses for working with ABAP have come from outside (yes, there's another world...). I'm thinking of topics like Clean Code, DevOps, OData, JSON and more. So why shouldn't the topic of security in ABAP also be enriched by know-how outside of the SAP ecosystem? 🤔

A first approach to the topic

In order to approach the topic, Marco first recommended a document from the German Federal Office for Information Security. It is open to the public, but in German. Title is "Umsetzungshinweise zum Baustein APP.4.6 SAP-ABAP Programmierung" (as of 05/31/2022).

So that the SAP/ABAP community worldwide can benefit from the know-how from the document, I have listed the most important, security-critical points and recommendations in English here:

1. Protection of reports with authorization checks: In order not to have to rely on each caller of a program (maybe via SE80 or SE38) to carry out an appropriate authorization check beforehand, each program should carry out an explicit authorization check that is appropriate to the program's context.


2. Correct evaluation of authorization checks: Pay attention to SY-SUBRC after calling AUTHORITY-CHECK.


3. Authorization check before starting a transaction: Use CALL TRANSACTION with option WITH AUTHORITY-CHECK (available from 7.40 on).


4. No proprietary authorization checks: No condition on SY-UNAME for example. Instead use AUTHORITY-CHECK.


5. Creation of a company guideline for ABAP development: No words. jelena.perfiljeva2  has written enough about that topic in this blog.


6. Complete execution of authorization checks: Respect all fields of a authorization object when using with AUTHORITY-CHECK.


7. Authorization check during input processing: Don't allow to execure function codes via command prompt of SAP GUI even if the corresponding function is not active.


8. Protection against unauthorized or manipulative access to the file system: Files for reading or writing should not be completely freely selectable. Note 1497003 and the function module FILE_VALIDATE_NAME should be read.


9. Authorization check in remote-capable function modules: Maybe someone remembers the function module RFC_READ_TABLE?


10. Prevention of the execution of operating system commands: If user input is used as part of the commands, this is critical.


11. Avoidance of injected malicious code: ABAP statements INSERT REPORT and GENERATE SUBROUTINE POOL can be used to execute malicious code that's hard to track.


12. Avoiding generic module execution: ABAP statement SUBMIT can be used to execute code without authorization.


13. Avoidance of generic access to table contents: If SELECT statement is used dynamically (table name and condition) and the values depend on user input, it's critically (some kind of SE16 rebuild?).


14. Avoidance of native SQL statements: Statement EXEC SQL or corresponding classes of ABAP Database Connectivity allow to execute specific database depending commands that bring more possibilities then ABAP SQL and avoid the Open SQL layer and the tracking.


15. Prevention of data leaks: In general, it should be determined which data is business-critical and may under no circumstances be exported from the SAP software in any form whatsoever (file, RFC and others).


16. No system-dependent function execution: Do not rely on SY-SYSID to execute system depending source code.


17. No client-dependent function execution: Do not rely on SY-MANDT to execute client depending source code.


18. Avoidance of Open SQL injection vulnerabilities: See note 1520356.


19. Protection against cross-site scripting: Avoid own written HTML in Business Server Pages or HTTP request handlern. Rely on Web Dynpro or UI5 generated HTML.


20. No access to data from another client: No use of SELECT statement with option CLIENT SPECIFIED or native SQL via EXEC SQL statement.


21. Prohibition of hidden ABAP source code: You can hide ABAP source code on older SAP NetWeaver releases and so nobody can check what you wrote.


22. Use of ABAP code analysis tools: Use tools like SAP Test Cockpit oder Code Inspector. Maybe a third party add-on with special focus.

Those were just the headlines with brief notes. In the original document, the chapters are much more detailed and I find the document very readable. Even if you don't understand everything (that's how I felt) it gives an insight that as an ABAP developer you have to pay attention to some security-critical aspects.

It is fair to say that some security-critical aspects are already taken into account by Clean ABAP. It's good! 🙂 Oh yes: And a lot revolves around authorization checks, but not everything 😄

More information

While searching for more information about ABAP and security, I stumbled across a guide from the German SAP User Group (DSAG). It is available in English and German (see chapter 5). SAP Press also published a book on the subject, which dates back to 2009 (ISBN 3836213575). I haven't read it but I believe that even it's from 2009 it will address some interesting topics that are still valid today. A lot of ABAP developments are used for a long time...

My own thoughts

In fact, authorization checks seem to play a big role for us ABAP developers. However, I have the feeling that many new security issues are coming our way. The above recommendations definitely apply to on-premises systems. In the meantime, however, we also have the Business Technology Platform and security could play a role here in completely new aspects.

Overall, we have more critical data than ever in SAP software. And there are more every day. At the same time, we are connecting on premises and cloud systems more closely. However, it has never been as easy as it is today to provide data via an interface. Think of "@OData.publish: true", side-by-side extensions and user interfaces via UI5 for any internet users (frontend - maybe not your well educated and trained company colleagues).

With all these changes, I guess there are also new security aspects for us ABAP developers to learn. I'm curious what your opinion is about and what you've already experienced here. So feel free to comment and discuss...

 

Best regards, thanks for reading and stay healthy

Michael