Risks of SE16

[Former Member]

I'm trying to understand the risks involved in assigning display access of SE16 in production. I would appreciate it if someone can give me a good explanation about this.

SAP note 13202 informs us that developers should not have access to any of the SE transactions unless really necessary. But I know that there are companies even those SOX-compliant ones that allow display and execute access to SE38 and display access for SE16 on a daily basis. Why is this when SAP tells us not to.

The functional folks currently have display of the img and is asking for SE16. Is it ok if I give them display access of SE16? Are there risks involved?

Thanks in advance!

[Former Member]

Hi

Here is one scenario:

Log in to an R/3 system with a user ID that has a very simple u201Cdisplay onlyu201D profile (e.g., the profile S_A.SHOW). Then run transaction SE16 and enter u201CUSR02u201D as the table name. Can you display this table? Can you download it (System u2192 List u2192 Save u2192 Local file)? If a user with a u201Cdisplay onlyu201D profile can display and download the table contents, give yourself a failing grade. USR02 is the table that contains master user logon data, and although not easy, it is possible for a technical expert with access to an SAP system to use this table for discovering (cracking) passwords. This means there is a security problem at the application and the presentation level.

<removed-by_moderator>

But there could be more things there !

Edited by: Julius Bussche on Jun 30, 2008 6:55 PM

[Former Member]

Deepak,

This is the second time today that you have posted something about SAP security which you have heard or read somewhere in the internet.

In the first case, your answer was quite obviously incorrect, and this one is very suspect: Could you please explain to me how it is possible for you to crack passwords (considering that you have posted this information)?

Cheers,

Julius

PS: I want to know this from you, not some spam from the internet which is mostly incorrect and incomplete!

[Former Member]

Hi Bliss,

With the correct development authorizations and SE16 there are backdoor "hacks" that could allow a knowledgeable individual to directly maintain table data which is a very risky scenario.

Probably a more prevelant risk is that individuals may be granted display access to sensitive data depending on how comprehensive the table security strategy is within your system. With SE16 what table groups will you grant access to with the S_TABU_DIS object? What tables are within these table groups? What sensitive data is stored in your SAP system? Are these tables secured with a specific table group? Is data encrypted within these tables?

Deepak's example with USR02 is one case in which wide access to even display data can be abused. I would by very careful granting table access especially if your system stores HR data, sensitive customer information such as credit cards, or other high risk data. Much of the risk of table display will be driven by the type of data within your system.

[Former Member]

>

> With the correct development authorizations and SE16 there are backdoor "hacks" that could allow a knowledgeable individual to directly maintain table data which is a very risky scenario.

Yes, that is correct. You can even navigate into the screens of other transactions. But this is not only limited to transaction SE16, and if the user has the correct authorizations to be able to use the screen, or run a report to completion, or what-ever SE16 and equivalent transactions are all capable of, then that is what you get for it.

Not falling too far behind on support package levels helps as well... but if someone has the skills and determination to use (or change) data in SAP tables, the object S_TCODE id 'TCD' field 'SE16' will not hinder them. You need to use granular auth object controls for that.

[Former Member]

What are some of these backdoor hacks?

[Former Member]

Hi Bliss,

As Julius correctly expanded upon my original comment, the risks of direct table maintenance are not necessarily dependent upon S_TCODE = SE16, but more lack of control around development objects. When I referred to "hacks" I was referencing the use of debug in conjunction with SE16 or SE16N to maintain table entries.

Table maintenance with SE16(N) has been discussed several times in the past and a search could probably yield some nice discussions.

[Former Member]

In addition to Julius, TDCumm16, there are many ways to access table data. SE16 is one of those & you could class debug as hacking, but there are many, many other ways of seeing or changing the data which fall under the auspices of standard, documented functionality & are not controlled by S_TCODE = SE16. Once yo uthink about how SAP works, a few spring to mind straight away.

[Former Member]

> What are some of these backdoor hacks?

I always laugh a bit to myself when I see these SE16 is worse than SAP_ALL type posts. No one ever complains about SE15, or SE14.

The only thing worse than that is to smack S_TCODE checks in allllll over the place to cure a different problem => lack of consistent granular security roles, and consistent granular security checks.

This is also partly the fault of auditors who go around writing audit reports about who has SE16 together with S_TABU_DIS *'s, and decide that locking SE16 is an okay solution...

Anyone who is scared of S_TCODE = SE16, is a wimp