ABAP Dumps containing Sensitive Data

[Former Member]

Hi Community,

We have a theoretical scenario where we want to develop an application that will require to handle Sensitive Data. This data is not persisted in SAP, rather brought in through an interface. There is going to be a custom authorization object created and roles based on that would restrict the use and visibility of this data to selected people. There are legal & IP ramifications to having this data even accidentally visible to unauthorized personnel.

Like any program in general, one cannot guarantee that the problem will never throw an error. So, there is a possibility of an ABAP Dump even in this sensitive program.If this were to happen then the "Chosen Variables" section of the dump,which randomly selects some variables to log, may have sensitive data in them. ABAP Dumps are visible to the entire support team in the company so that is unacceptable.

So the question is, is there any way we can hide the "Chosen Variables" section in ABAP Dumps? Or preferably, is there any way in which we can guarentee that certain variables and internal tables will never get chosen to be put in the ABAP Dump?

This little issue can potentially stop a big implementation that we are in the middle of.

Any help would be greatly appreciated.

Thanks & Regards,

Varun Rangabhashyam

[former_member221827]

Never messed with it myself, but looks to me like the code for displaying these variables is in report MS380F20 subroutine "form display_variables".

You could possibly use an implicit enhancement to prevent these variables from displaying.

[vijay_hariharan]

Hi Varun,

To start with, this is a Weird requirement.

The Purpose of an ABAP Dump variables is to inform the Support team/Developer on which data went into error and why. Based on what i read from your requirement, there a few things that you might need to consider:

1. There are many System variables set and displayed when there is an ABAP Dump. What values might get displayed depends on what sort of Dump occurs

2. There are Chosen variable values as per the Program call Stack, you'll need to take care if there are nested sub-routine calls

3. The Description of the Dump itself might contain value(rare case)

Ideally a Custom ABAP program should never go into Dump. Common reasons are Time out because of large data, Conversion errors, Parameter missing, data-type change etc. Check if you can cover all this in your code itself with a TRY CATCH along with having the enhancement mentioned above to hide chosen variables(if possible).

Without thorough analysis/test this can be a tricky promise to make.

Regards,

Vijay

[Former Member]

Thanks for your detailed response Vijay. I understand that my question is the reverse of conventional wisdom but that is the situation here.

We are talking of the rarest of rare situations here. To elaborate, a dump would be very rare in Custom Code and even in that dump chances of 1 of the randomly "Chosen Variables" containing sensitive data is low. But if that were to happen, we risk having a Legal Issue - and hence we need to plug even this pinhole.

Hence my question to the experts.

[Former Member]

On further thought and analysis I have realized that I made an Assumption that might be faulty. I believe that all dumps cannot be caught within a TRY CATCH block - in other words, there are certain types of Dump's that are non-catchable.

Is my Assumption here correct?

[Former Member]

Hi Varun,

I don´t know if there is a way to "customize" the Data that is stored in a dump.

But there may be a few way´s to get another solution for your problem.

Easiest way would be to close the ST22. As far as I remember there are is an authorization check for the dump display. Not enough rights and you could only see THAT a dump occurred. But not the content.

So only a chosen team of developer could take a look into the dump data.

All "normal" dumps could be exported in HTML/PDF/... so that the other developers can analyse those dumps. And the special dumps are just for people with security clearance.

Another (i think ugly) way would be to regularly search the dumps for "dangerous" objects/reports make a secured backup and delete those dumps.

All dump data could be found in the databasetable "SNAP".

The data is a bit cryptical in there.

The header, the variables and so on are listed in the -FLIST* strings.

The first two digits are the type of the information (for example AP for a variable name). The next three digits are the length of the content. And the following digits (length was specified in the signs before) is the content. And then it begins again

For example:

SNAP-FLIST = AP005MyVarTD01500123456789101

=> AP     - MyVar

     TD     - 001213456789101

Just take a look at "RSSHOWRABAX" in the form "EXTRACT_STRINGS_FROM_SNAP". There is the coding how to read a dump. I think I saw somewhere a "new" implementation  in ABAP OO.

I would screen the ABAP Stack for relevant objects. I there is a object that may contain dangerous data => secure backup and delete of the SNAP entry.

With a customizing table, a report that does the job and a periodical start of that report you could make sure, that "sensitive data" is only a very short time accessible.

I don´t know how it is done with UnitTests, but my UnitTests never created a real dump. Everytime the UnitTest-Framework kicked in and catched my runtime error. Perhaps there is a possible way to catch all these nasty dumps. But then you have to create your own, secure, loging mechanism, so that someone have the chance to analyse those catched runtime errors

I would prefere the first solution with reduced authorizations for the developers on the productive system.

warm regards

Jan

[Former Member]

First of all, thanks a lot for your detailed response Jan.

I don´t know if there is a way to "customize" the Data that is stored in a dump.

This would be the ideal solution if it were possible.

Easiest way would be to close the ST22

Agreed again - but this is the situation that we are trying to avoid. To do this would be to throw off an established support structure in my organization. So, this could work but I would like to keep it as a last alternative.

One more thing this does not answer is the fact that if there was confidential data in a dump then it could be viewed directly in the database (in cryptic format - but this entire exercise is theoretical to cover legal loose ends). Although the SNAP Table itself is covered because of "Delivery/Maintenance" is not allowed, the view SNAP_BEG is open to viewed through standard tools like SE16.

Another (i think ugly) way would be to regularly search the dumps for "dangerous" objects/reports make a secured backup and delete those dumps.

This to me seems to be the only way in which we can go if we want to implement the solution in SAP. In this regard I was wondering if there is an Event or something similar raised when a Dump occurs - it would be better to implement the logic you suggested off an event rather than a regularly scheduled job. Also, we could use the API available through the class CL_RUNTIME_ERROR (Method GET_CHOSEN_VARIABLES).

Thanks again for your response.

Regards,

Varun

[Former Member]

Hi Varun,

thanks for the "CL_RUNTIME_ERROR" class. When I searched for something like that, I missed this one. 🙂

Because UNIT-TESTS are able to catch any runtime error (at least a never saw a case where a runtime error get through), I thougth that there must be a way to catch those nasty things.

But it seems that this catching is not done in normal ABAP, but on system level. So there may be no way for "normal" developers to get the same safety.

So I fear you have only a few possibilities:

- change the support process and cut the authorizations to a minimum

- write a program that searches and deletes relevant snap entries (must run in a tight schedule)

- code the application extreme defensivly to reduce the risk of short dumps to a minimum

-- code the application with a minimum of sensible data at the same time in the memory.

Or...

- the company has to live with the risc 😞

warm regards.

Jan