After finishing the last post on SE16N and DEBUG, I realised that since this site primarily caters to the aspiring security consultants, some portion of its target audience might be at all familiar with ABAP debugging at all. The idea behind this post is to acquaint Security Consultants with the basics of debugging. This is certainly not meant as a guide on how to debug ABAP code as you would need to be familiar with ABAP syntax to actually debug code. However, I always consider that knowing ABAP is very helpful for any consultant, functional, security or basis. So if you have some free time you can always go through some of the free ABAP tutorials available on the web and the added knowledge would certainly come in handy the longer you stay with SAP. Continue reading “ABAP Debugger”
Few aspects of SAP Security are as well explored by Security Consultants as security for Tables. SAP already provides a host of objects for controlling access to tables – S_TABU_DIS for security through table authorization groups, S_TABU_CLI for client independent tables, S_TABU_LIN for row level security and S_TABU_NAM for security individual tables. The use of these different authorization objects have been documented elsewhere on this blog and I would not want to discuss any more of them here. However, lets take a different approach and think about a way to secure individual fields for a table or in other words column level security for a table. One of the ways to achieve these is through the use of database views. Please note that creating database view is not the job of a security consultant and in all probablity you would not have access to do it in any system. However its good to know of the option if ever the need arises. Continue reading “Database Views For Tables”
Transaction variants allows us to selectively mask certain fields in SAP transactions/screens. Though strictly not a security tool, transaction variants can have applications in security by helping to prevent users from updating fields which are not protected through authorization objects
Transaction Variants are created trough the SHD0 t-code. The initial screen SHD0 is given below. To create a transaction variant we mention the name of the parent transaction, give a name of the variant and click the create button.
In our example below, we create a transaction variant ZSU01 for the very common SU01 tcode. The transaction variant allows an administrator only to reset passwords and hides all other functions of SU01. Each transaction variant contains of one or more screen variants depending on the number of screens being called in the entire transaction flow. We don’t have to manually keep track of the screen variants when we are working with transaction variants. As we move from one screen to the next, SHD0 automatically creates and appends a new screen variant to the sequence.
On clicking the create button for ZSU01, we are taken to the standard SU01 screen. We enter a user name and click the change password button. A pop-up window appears with a list of the screen fields. This window contains the attributes of our first screen variant. Its here where we enter a name of the screen variant and can selectively mark screen fields to invisible/output only/required, etc.
The screen variant window has a button for “Menu Functions” where we can selectively hide/de-activate menu items or toolbar buttons. Since our intention is to disable everything except password change options, we end up with below screen.
On clicking the check button from the screen variant we are taken to the next screen and need to save our entries for the password change screen.
On clicking, the save and exit button we are taken to the overview screen for the transaction variant. As shown below, this screen gives the definition of the individual screen variants which form part of the transaction variant. On saving our entries, we are taken to the SHD0 initial screen which shows the transaction variant and the screen variants defined under it.
SHD0 provides a test button here we can check if the newly created transaction variants works as per our requirement. Once tested we create a new Z transaction (ZSU01) for the transaction variant by following the menu path Goto>Create Variant Transaction.
Once set up, this new transaction can be assigned to a user’s role just like a normal transaction. Executing, ZSU01 display a modified form of SU01 screen with all functions other than change password button is disabled.
We have already come across LSMW for mass changes to SAP data. Let us not assume that LSMW is the only tool which can be used to update data in SAP. SAP provides quite a few number of tools, each with its unique features, to allow mass updation of data. In the current article I talk about the Transaction Recorder tool which can be accessed through the transaction SHDB. Like LSMW, SHDB is also used to record certain user actions in the SAP GUI for a particular transaction. These actions are used to create a recording which can be processed at a later time to upload data. Through SHDB it is also quite easy to generate an ABAP report from the recording and modify the generated code to read an input file with a list of records and upload the data though the program. In this article I demonstrate the entire sequence of actions though a recording to reset the password of a user through SU01.
We start the transaction SHDB and click the button for new recording. We give an appropriate name for the recording and input the transaction (SU01 in this case) which we are trying to record.
On clicking the check button, we are taken to the normal SU01 screen where we rest the password of any user id already created in the system (USER01).
On saving the new password and clicking the back button, we are returned SHDB where we can check the steps in the recording.
To test the recording we change the user id to “USER02” and save the recording. Now we can process the recording from SHDB.
On successful processing for the recording, we get a screen showing that password for USER02 was indeed changed.
Although its technically feasible to manually change the data in the recording and process them through SHDB, the generally accepted approach is to generate a program for the recording and update a list of records though ABAP code. SHDB main screen has options to generate a program from recording.
On selecting this option, SHDB prompts us for the attribute details for the program and generates a skeleton code for the recording. We can now update this skeleton code to read data records from a file into an internal table, and loop over each record to update data into SAP. I am not adding the final code in this example but the basic skeleton is given below.
As you can see from the above example, like LSMW, SHDB provides us with another alternate method of upload of data into a SAP system. Which method you finally chose depends a lot on whether you are more comfortable in writing code or creating a the LSMW script.
Often a security administrator comes across requirements where the existing authorization objects delivered by SAP is not enough. Mostly these come during custom developments through completely new programs or enhancements to existing SAP programs. In such situations, SAP provides us with the option of defining completely new authorization objects. The names of these customer specific objects should begin with Y or Z and can be created through the SU21 transaction. If required we can define new authorization fields as well through the transaction SU20.
In the example below, we are set to create a new authorization field and use it in a new authorization object. First we go into Su20 and select the create option from the toolbar. We create a new field “ZBOOLEAN” which takes two possible values ‘X’ and ‘ ‘. The possible values for a field are controlled by the definition of the data element specified in the ABAP dictionary, in this case which is BOOLE_D. We might create our own data elements as well through SE11 transaction. On saving the new field we are prompted for a package for our new development. Packages are dictionary objects to group similar objects for transporting across development, quality assurance and production systems. We if do not plan to transport the new field we can select the local object (package $TMP) from the options.
Once the authorization field is created, its time to include it in a custom authorization object through Su21. We select the authorization class of the object and select the crate option. (Su21 also allows us to create our own authorization classes. Its a good practice to create at least one Z or Y authorization class to include our custom authorization objects).
We define the authorization field(s) for the new authorization object. Like the SAP delivered objects we are limited to a maximum of ten fields for custom objects as well. We should create some object documentation as well for future reference. On saving the new object we are again prompted for a package and we have the option of specifying a particular package or creating the new development as a local object. Typically at this point, the security administrator will contact the ABAP programmer to include a check for the new object in his code.
New t-codes can be created through the transaction SE93. In the example below, the t-code is created to call a program during execution. We can also create parameter transactions to which call standard sap transactions (like SE16 or SM30) or launch an ABAP query.
From the security perspective SE93 allows us to add a value for the authorization object field. This authorization object with the values specified for its fields, will be checked in addition to S_TCODE before the transaction is started.
Below we see the Se93 entry for the common HR t-code PP01. To start this transaction an user would need P_TCODE with TCD value PP01 in his user buffer, in addition to S_TCODE entry.
This post talks about the program level mechanism to implement a check for a particular authorization object. SAP Business applications are coded in the SAP proprietary language, ABAP. All transactions call ABAP programs at the back-end and it is this code which is responsible for checking security.
The security check for an authorization object is through the standard ABAP construct “AUTHORITY-CHECK”. The actual form of this statement is given below for checking display access (ACTVT 03) to a table belonging to particular table authorization group (DIBERCLS ‘SC’).
AUTHORITY-CHECK OBJECT ‘S_TABU_DIS’
ID ‘ACTVT’ FIELD ’03’
ID ‘DIBERCLS’ FIELD ‘SC’.
Copying a portion of the SAP code which is used to check for table access
This statement checks the user buffer of the person executing the program/ tcode to see if he has an authorization for S_TABU_DIS with actvt 03 and dibercls ‘sc’. Depending on the contents of the user buffer, the statement might return different values (the values of the sytem field SY-SUBRC)
- 0 signifies a succesfull check, i.e. user has the correct authorization
- 4 denotes user has the authorization object in the buffer but not with the correct values
- 12 denotes that the user has no authorizations for the specified object