SAP Table Authorizations

8/12/2019 SAP Table Authorizations

1/12

SAP table authorizationsAgenda

1. Standard S_TABU_* authorization checks1. Controlling access by authorization group2. Controlling access by table name3. Cross-client table maintenance4. Overview

2. A deeper look at SE16, SM30 and friends1. Direct program invocation2. Redundant transactions3. Weak parameter transactions

3. Other ways to get hold of table data1. Customer programs2. Function modules3.

Debug with replace4. Transport requests

4. Conclusion1. Standard S_TABU_* authorization checksSecurity consultants are often asked to check/ensure secured access to tables.So, let's see how SAP allows us to limit directtable access. "Direct", as we aredealing with the SAP standard tools for displaying table data on-screen in thisarticle not to be confused with business transactions that work with (the same)table data, too.

Therefore, the scope of this article is:

o Standard table browsing and maintenance transactions: SE16, SE16N, SE17, SM30,SM31 et al.

o Proxy-transactions like SPRO (which call the aforementioned ones internally)o SAP Query (SQVI, SQ01, )

(btw.: the standard table authorizations checked in the above transactions arepotentially checked in other tcodes as well, but that's another topic)

1.1. Controlling access by authorization groupThe authorization object S_TABU_DIS controls access to tables via an Activity(ACTVT) in combination with a Table Authorization Group (DICBERCLS dictionary Berechtigungs-class nice denglish, SAP ).Table Auth. Groups combine an arbitrary number of tables with a similar"purpose" or contents; e.g. the group "SC" ("RS: User control") includeshundreds of tables containing user master-, address-, audit- and similar data.Each table can only be assigned to a single Table Auth. Group.
http://www.daniel-berlin.de/security/sap-sec/table-authorizations/http://www.daniel-berlin.de/security/sap-sec/table-authorizations/


2/12

You can check a table's group via SE54 or directly via SE16 (table TTDAT, fieldCCLASS):

The purpose of a Table Authorization Group (or at least its humble description)can be found in table TBRGT(go for BROBJ = "S_TABU_DIS", BRGRU = and check the BEZEI field):

The assignment of tables to Table Auth. Groups can be maintained in SE54 (ordirectly via SM30 for view V_DDAT_54).

So with S_TABU_DIS we're able to grant access "by purpose" which soundsgood and is in fact rather useful but there are some downsides:

o less than 20%of all tables are assigned to a Table Auth. Group on a recent IDESsystem and the rest ? all other tables automatically belong to the fallback group"&NC&" (= "not classified").If you want to check this yourself, just compare the number of entries in tableDD02L (with AS4LOCAL = "A") to the number of entries in TDDAT (with CCLASS "&NC&" and "").

o you always have to grant access to all tables linked to a group, which oftenfeels like taking a sledgehammer to crack a nut. This is a major lack of granularity!

1.2. Controlling access by table nameIn recent releases, SAP introduced a new authorization object, which finally

offers fine-grained control: S_TABU_NAM ("Table Access via Generic StandardTools"):


3/12

It allows granting access by individual tables names (wildcards are allowed, butonly at the end of the TABLE value). S_TABU_NAM and is only considered, if aprevious check for S_TABU_DIS failed (it's an additional check afterS_TABU_DIS, not a replacement). Thus, it's now possible to grant display accessto a complete Table Auth. Group while limiting maintenance rights to selectedtables in that group.

Check out SAPNote 1481950,Note 1500054and the related ones mentioned

thereinstrongly recommended.

1.3. Cross-client table maintenanceClient-independent tables are shared among all clients of a SAP system;modifications to their contents have an impact on the whole system. Hence,changes to them require special care and must only be allowed for users whoknow about the possible side-effects. SAP mitigated this problem by providinga supplementary authorization object, which is only checked when trying tomaintain client-independent tables in additionto S_TABU_DIS and _NAM:S_TABU_CLI ("Cross-Client Table Maintenance"). The allowed values for its only

field CLIIDMAINT are "X" (allowed) and " " (not allowed). Most client-independent tables are customizing tables, so the main audience for this right isadministrators and supporters.

1.4. OverviewAt this point, we can summarize the complete flow of authorization checks fortable access:

o first S_TABU_DIS is checked using the table's authorization group (or the dummygroup "&NC&" if none is set)

o

only if this fails, S_TABU_NAM is checked for the table nameo on success and in case the user wants to modify (not display) a client-independent

table, an additional objectS_TABU_CLIis checked
https://service.sap.com/sap/support/notes/1481950https://service.sap.com/sap/support/notes/1481950https://service.sap.com/sap/support/notes/1481950https://service.sap.com/sap/support/notes/1500054https://service.sap.com/sap/support/notes/1500054https://service.sap.com/sap/support/notes/1500054https://service.sap.com/sap/support/notes/1500054https://service.sap.com/sap/support/notes/1481950


4/12

2. A deeper look at SE16, SM30 and friendsAt this point, we took a look at the basic measures for table protection; it is timefor the pitfalls one might want to avoid!

A common mistake, (overworked) authorization admins often make when they'reasked to clean up table authorizations is to just remove SE16 etc. from S_TCODEbut leave S_TABU_* as it is.

So, what is the problem with table authorizations without the correspondingtcodes ? Simple answer: many roads lead to Rome!read on

2.1. Direct program invocationTransactions are nothing but a convenient way to execute programs, optionallypassing parameters along.

Let's check via SE93, what exactly is behind SE16 and SM30 (check the otherones yourself):

o SE16 calls SAPLSETB, which is a function pool ( function pools are not directlyexecutable)

o SE16N executes the report RK_SE16N ( executable)o SM30 and SM31 call SAPMSVMAa module pool ( not directly executable; almost

* )This means, removing SE16N from S_TCODE, but allowing for instance SA38 orSTART_REPORT does not necessarily prevent direct table access.It's not a big deal, since table authorizations are checked as usual but keep inmind: removing the tcodes from S_TCODE has a limited effect unless you alsotake care of S_TABU_*, S_PROGRAM and S_DEVELOP (check SAPNote 1012066for the last one)!
https://service.sap.com/sap/support/notes/1012066https://service.sap.com/sap/support/notes/1012066https://service.sap.com/sap/support/notes/1012066https://service.sap.com/sap/support/notes/1012066


5/12

(*) Direct module pool execution is possible through a strange speciality in SE38:if a module pool name is entered in the firstscreen and then executed, SAPinternally searches for tcodes using the same program ("SELECT * FROM tstcWHERE pgmna = ") and arbitrarily executes the first one! This is donein class CL_WB_PGEDITOR, method EXECUTE.

2.2. Redundant transactionsIn the last chapter, we've identified the programs behind the most common tabletransactions. Unfortunately, they're not the only ones, which point to theunderlying programs. A user might hit on the idea to search for a tcode, whichexecutes a program he/she isn't allowed to execute directly SE16 or SM30 inour case.

To assess this risk, we have to search for other tcodes (in table TSTC), whichuse the same programs (in the field PGMNA). Check your system!

2.3. Weak parameter transactionsParameter transactions execute an existing transaction delivering pre-definedscreen input.

For example, the transaction code SM30_PRGN_CUST is a shortcut to SM30 forthe maintenance view PRGN_CUST. When you call it, SM30 is executed with"PRGN_CUST" in maintenance mode. Since the option "Skip initial screen" isselected, this tcode jumps directly into the table maintenance view itselfif itwasn't selected, one would be able to override the given screen options,including the table name! That's the point where the weakness starts.

Have a look at these parameter transactions from table TSTCP:

The first oneVYCMis safe, because the "/*" indicates that the first screen isskipped and thus the view name cannot be overridden. The second one VYCQ

just calls SM30 and fills in the given view name "TKKVBLERM" leaving the

choice of the actual view name up to the user (due to "/N")!

So, to determine all unsafe parameter transactions for SE16, SM30 you need tosearch for PARAMs matching "/N" (e.g. "/NSM30*").

3. Other ways to get hold of table dataNow we're ready to face the truth: there are ways to avoid S_TABU_* checks!


6/12

3.1. Customer programsAll customer programs are as secure as the developers made them!To scare your boss, just show him/her something like this:

REPORT.

TABLES:pa0008. " HR Master Record: Infotype 0008 (Basic Pay)

SELECT*FROMpa0008 CLIENT SPECIFIED.

" SAP Client, User Name, Personnel Number, Annual Salary

WRITE:/pa0008-mandt,pa0008-uname,pa0008-pernr,pa0008-ansal.

ENDSELECT.

Ways to mitigate this risk include:

o organizational: add a "code check" step to your company's transport process (i.e. 4eyes principle)

o internal control: perform a regular control of customer programs (e.g. via reportRS_ABAP_SOURCE_SCAN)but be aware, that this is not safe due to codeobfuscation

3.2. Function modulesMany function modules do not perform (sensible) authorization checks, as theyare intended to be called from within reportswhich are assumed to do those

checks instead. If users are allowed to "test" (i.e. execute) FMs, most protectionmeasures become pointless! Concerning table access, this means that in theworst case, the standard checks from the first chapter are just ignored.

Try SE37 with "TRINT_DISPLAY_TABLE_CONTENTS" to view any table you want!This is what you need:

OBJECT FIELD VALUE

S_TCODE TCD SE37

S_DEVELOP ACTVT 03


7/12

OBJECT FIELD VALUE

DEVCLASS ' '

OBJNAME ' '

OBJTYPE ' '

P_GROUP ' '

S_DEVELOP

ACTVT 16

DEVCLASS SCTS_REQ

OBJNAME STRJ

OBJTYPE FUGR

P_GROUP ' '

ouchno S_TABU_* check!

3.3. Debug with replace


8/12

Allowing users to debug with replace (i.e. S_DEVELOP with object type DEBUGand ACTVT 02 & 03) is extremely dangerous, since it allows stepping overparts of the code (e.g. AUTHORITY-CHECKs) and change field values (e.g. SY-SUBRC thereafter)! This means that almost all authorization checks are useless,as they can be bypassed or the return code can be changed. The only checks,which are unavoidable, are kernel-based authorization checkslike S_DATASET.

Example: to display the contents of any table, you only need to set threebreakpoints in the includes LSUSEU11, LSETBU03and LSVIXU16. This can easilybe accomplished with the following authorizations (attn.: this is neither thesmallest nor the only possible set of authorizations):

OBJECT FIELD VALUE

S_TCODE TCD SE38

S_DEVELOP

ACTVT 03

DEVCLASS S*

OBJNAME S*

OBJTYPE FUGR

P_GROUP ' '

S_DEVELOP ACTVT 02, 03


9/12

OBJECT FIELD VALUE

DEVCLASS ' '

OBJNAME ' '

OBJTYPE DEBUG

P_GROUP ' '

Watch out: replacing variables creates a system log message; check SM21!

3.4. Transport requestsTable contents contained in transport requests can be viewed without a singleS_TABU_* check

Being authorized to create a new transport request and include a tables contentsis equal to SE16. Btw, there is no need to release the request; it can even bedeleted laterwithout leaving significant traces.


10/12

Try this at home (while running an authorization trace):

and then


11/12

et voil.

See also SAPNote 1237762Solution Item 4.

4. ConclusionThe main points of this article are:

o S_TABU_DIS is suitable for users, who need access to many tables, i.e. admins andmost supporters

o explicitly assigning a table to group "&NC&" via SE54 has absolutely no effect itthe same as no entry in TDDAT at all

o S_TABU_NAM is good for users, who only need access to a small number of well-known tables, i.e. some supporters and few business (key-) users

o S_TABU_CLI is strictly for SAP basis admins, especially for (but not limited to)multi-client systems
https://service.sap.com/sap/support/notes/1237762https://service.sap.com/sap/support/notes/1237762https://service.sap.com/sap/support/notes/1237762https://service.sap.com/sap/support/notes/1237762


12/12

o table data access is not limited to the standard tcodes SE16(N), SM30 etc.manyother ways exist

o direct report execution is sometimes necessary, but might be evilbe carefulo search your system for alternative tcodes and weak parameter transactions

(especially Y and Z ones)

o being able to test function modules on production is russian roulette for yoursystem security!

o don't let your programmers transport without (ex-ante or ex-post) inspectiono debug with replace on any productive system is evil! really!o being able to create transport requests on production opens insecurities as big as a

barn door (but might be necessary during support package installations)

Documents

SAP Table Authorizations