Building Secure Transactions on SAP Systems
Even though SAP has more than 10,000 standard transactions, all companies create their own custom ones. There are different reasons for building custom transactions. For example, a user might need a specific report, a list, or a functionality that isn't in the system. Sometimes there are even cases where custom transactions with identical functionality of an existing standard transaction are created. Creating custom transactions isn't a problem, it is a normal usage of the system. The problem however, is all the potential security issues related to these new transactions. When building custom programs, the priority is focused on delivering the required functionality to the user, which usually results in security measures being left aside. It is common to find ABAP developers who aren't concerned with the importance of security or are simply unaware of all the security mechanisms SAP offers to enforce security. They just ensure that the program is working properly based on what the user had requested. Once it's created, someone else adds the tcode to the user role, and that is it. So the question is how can we ensure that in our organization custom transactions are built in a secure way? The answer is easy: Use ABAP security standards - BIZEC APP11 as a guide to create the transactions. Easy to say, but hard to do. The standard includes different types of possible misconfigurations:
- APP-01 ABAP Command Injection
- APP-02 OS Command Injection
- APP-03 Native SQL Injection
- APP-04 Improper Authorization
- APP-05 Directory Traversal
- APP-06 Direct Database Modifications
- APP-07 Cross-Client Database Access
- APP-08 Open SQL Injection
- APP-09 Generic Module Execution
- APP-10 Cross-Site Scripting
- APP-11 Obscure ABAP Code
In this blogpost I want to focus on the APP-04-Improper Authorization:
How to choose the right Authorization Object for each transaction?
First of all, someone who understands SAP security concepts should be involved in this task and needs to:
- Understand the user requirements, what the transaction should do.
- Look for similar standard transactions.
- Check which users will execute the tcode, and see the roles assigned to these users.
Let's illustrate this with an example; Someone requests a custom transaction to list Vendor Master Data in a certain report. This action can be linked with the existing tcode XK03-Display Vendor Master Data. I know that this case sounds very easy, but in general all the custom transactions are linked to an existing process, it’s just a matter of finding the right one. Once we have the related standard tcode, we need to find the relevant authorization objects. In order to do this, we can either execute a trace, or check transaction SU24 (or table USOBX), where we will find different authorization objects. In this case we can see that the most relevant authorization objects are the ones from the F_LFA1 family. According to the naming convention, the "F" represents the SAP module in this case F=Finance. LFA1 is the main table where the data is stored, which in this case, is the Vendor General Master Data.
The next step is to determine which type of segregation of access we need to put in place. For example, with the F_LFA1 auth objects we can segregate by:
- Company codes -> F_LFA1_BUK.
- Vendor account group -> F_LFA1_GRP.
- Authorization group -> F_LFA1_BEK.
It is also important to select the proper Activity (field ACTVT). This depends on the objective of the custom tcode:
- If the tcode will be used for creating new vendors the authority check should validate value "01".
- For changing existing vendors -> value "02"
- For displaying -> value "03"
If you think that your work is finished once the authority check is included in the transaction, you're still missing something. You are not done until the transaction is in Production, and before transporting it needs to be tested. Again, the priority of the testers is on checking that it works properly. However, it is important to remind them to test the security in order to see if the authority check is working properly. This can be done by creating a new role with the tcode and the required auth objects, and another role with just the tcode. Then, test that the first one can successfully run the transaction and that the second shows a lack of authorization warning. Before starting this test turn on the trace (ST01 transaction) to check the results of the authorization checks. The last point to take into account, is that custom transactions should be also considered in the Segregation of Duties (SoD) matrix, so we need to evaluate if the new transactions are related to any process that we consider incompatible with another one. For the rest of the BIZEC APP11 it's important to look for any forbidden code, such as command injection or native SQL.