Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
andrea_olivieri
Contributor

The Beginning...

The TIP: Editing any table in SAP!!! posted by Kevin Wilson a few days ago about the chance to modify the content of SAP tables using the SE16N transaction reminded me the importance of properly managing these tasks in a productive environment:

  • System settings (e.g. SCC4/SE06)
  • Permissions to perform certain actions and / or transactions.

Just to stay on the subject, I would like to share with the great SDN community a pearl which is based upon one of the peculiarities introduced by the new ABAP debugger.

My colleague Sandro Garofano (he's really a PI Guru) asked me: <<Hey Andrea, can you change the variable SY-UNAME while debugging?>>

Knowing the classic debugger and imagining to have the same behavior even with the new one, I answered with no doubt: <<Absolutely NOT!>>

Sandro then closed the conversation by adding: <<... Anyway, we did a test; if you change the content of the system variable sy-uname, the new debugger maintains the value ... Try it!>>

Later that Day: The test

In order to create the test case in my trial system I tried to display the users that have changed the field net weight of a particular material.

The first thing I did was identify a material code in the material master

then I've created a simple ABAP report which uses the Bapi method BAPI_MATERIAL_SAVEREPLICA in order to change the net weight value of the material.

In the ABAP program, I used a static BREAK-POINT statement, which activated the debugger immediately before the execution of the BAPI method  and this, allowed me to change the value of the field SY-UNAME. Of course the new debugger was activated.

The value of the system field SY-UNAME that I replaced while debugging was not restored by the system as shown by the following program log ...

..and the result is that the user SPIDERMAN changed the material!

Now we have two options:

  • The first is that SPIDERMAN really exists and he logged on the system just to change the material, once heroes had something more important to take care of...
  • The second one , the ABAP debugger was changed and SPIDERMAN is still busy with other stuffs

Later that day, too much later: another test

I was still wondering about SPIDERMAN in the night and I couldn't sleep.

So I connected to the same system and performed the same test but this time I used the classical debugger, but now, as supposed, the change was registered with my user-id because  the replacement of the system fields was not allowed

In fact, with the old debugger, the system resets the value immediately after pressing the key F5 (Single Step Key) and before the execution of the following statement.

So the execution log of the sample program looked like:

and this time SPIDERMAN was not able to change the material!

So the old debugger behavior didn't allow SPIDERMAN to edit the material or just SPIDERMAN was taking care of some enemies during the night?

The question

The morning after, waking up as a SAP consultant, my first question was: shall the behavior of the new debugger be considered as a new feature or is it a bug in the debugger?

Important aspects of the kernel and differences in behavior between the new and the classical debugger

The SYST fields are not write protected, so it's possible to change their value either in the debugger or by a corresponding ABAP statement in an application .

The second chance  is less worrying; in ABAP you could make a good MOVE ‘GOBLIN' TO SY-UNAME with the same effect, but this action requires changes to the program, the creation of a transport request and then an import into the productive system.

However the system fields SYST are reset by the kernel when a screen change happens ad this is the major reason for the difference in behavior between the new and the old debugger.

The old debugger runs in the same process as the application, and the debugger screens are inserted between the application screens; so any debugger step involves a screen change which resets the SYST fields and this is the reason why SY-UNAME reverts to its old value in the old debugger.

The new debugger,instead, is a two-process debugger. This means that debugger steps do not involve a screen change in the application which is under debugger control. Therefore the SYST fields are not being reset.

Security Risk

From a security point of view, replacing the value of the field SY-UNAME didn't give me the authorizations of the new person, because the roles are cached in memory and the authority-checks continue to fire against this cache of true identity; this means that I'll never have the SPIDERMAN's superpowers 😞

The only possible risk is that an audit trail could be altered by this way of replacing the system field SY-UNAME while debugging, so SPIDERMAN could results as a real employee...

Lesson learned:

As for the open source , the software is more secure if there are fewer secrets.  So It is important to take the necessary precautions.

Due to the fact that with the new debugger, changed system variables are not restored, functionalities like SE16N are even more dangerous and it's more and more important to disable them in any productive environment.

Unfortunately this is not always true so, as SPIDERMAN knows very well, with great power comes great responsibility...

Special thanks:

I would like to thank my colleague @ Techedge Sergio Cipolla for supporting the idea and for giving me the passion to blog on SDN

1 Comment