Hi there.

In this article, we’ll take a look at a potential weakness that is often considered minor and thus underrated – but might still be used to lever out important security measures: parameter transactions.
They basically execute another tcode… along with pre-defined screen input – the “parameters”.
For example, the transaction code SM30_PRGN_CUST is a shortcut to SM30 for the maintenance view PRGN_CUST:
When you call it, SM30 is executed and table PRGN_CUST is opened in maintenance mode. Since the option “Skip initial screen” is enabled, it jumps directly into the table maintenance view itself – if it was disabled, one would be able to override the given screen options in the SM30 Dynpro… including the table name! That’s the point where the weakness starts.
Now let’s select some more parameter transactions from table TSTCP.
They start with either “/*” or “/N” — the first one skips the called tcode’s initial screen, the latter one doesn’t.
Below you can find the selection options for all SE38 parameter transactions:

Now let’s have a look at the lines marked red and green in our result:

The first one – SE38L – is unsafe, because the “/N” indicates that the SE38 selection screen is just filled out – but the report name can be overridden easily.
This means that SE38L is equivalent to SE38 ❗
Well… for SE38L, -M, -N this might not be a big surprise, but what about RBDCPCLR? … I never would have guessed!

The second sample – SE38N – calls SE38 and executes report RDELALOG immediately: nothing to see here, move along.
Lessons learned
- When you limit access to a transaction, always keep in mind that insecure parameter transactions might represent a backdoor.
- Customer parameter transactions should always use the “Skip initial screen” option.
See you soon!