Hello everybody!
A few months passed since my last post, so it’s about time for new one! 💡
User names in conditional expressions

The system field SY-UNAME contains the name of the currently logged-on user and is quite frequently used by developers to facilitate tests by adding special conditions to their code. The block of code that is executed depending on the current user’s name is usually only intended for the developer him-/herself.
Although developer guidelines almost always include the obligation to make use of AUTHORITY-CHECKs, these checks might interfere with functional tests – and people might want to circumvent them (just for the tests, of course). No matter what the intention was, this approach leads to programs that do authorization checks for all users – except for the developer of the code… bad thing!
The following code snippet is probably one of the most prominent examples:
IF sy-uname NE 'DEVELOPER'. AUTHORITY-CHECK ... ENDIF. |
Right after the successful test phase, the code is transported to production and the conditional code might never be made universal…
If we consider malicious behavior, such code is called a backdoor and/or hidden function and this means that there is a need for action (at least to protect your developer colleagues)!
How to detect it
To find affected code, the SAP standard report RS_ABAP_SOURCE_SCAN is of great help — you can use it to search for plain strings or expressions in reports, classes, etc.
Since we’re interested in IF conditions that check the value of SY-UNAME, I’d suggest to search using “IF .*sy-uname” as the expression and tick the checkbox “String is standard expression“.
In the sample below, I limited the search to programs with name Z*, but you might probably want to adjust this according to your needs (e.g. your registered namespaces).

The result shows two different conditions that use SY-UNAME in a possibly evil way:

Detection gaps
The search expression above is rather straight forward…
Unfortunately, it can be tricked easily by a developer, who knows it:
DATA: foobar TYPE syuname. foobar = sy-uname. * Obfuscated condition IF foobar NE 'MYSELF'. AUTHORITY-CHECK ... ENDIF. |
So – when you establish controls to prevent the usage of user-based conditions, this is something to keep in mind.
Humans are usually better at detecting fuzzy patterns that computers are… 😎
Countermeasures
Code that is bypassed based on the value of SY-UNAME should never be used!
➡ All instances of hard-coded user names in customer code used on productive systems should be corrected.
➡ Controls should be established to prevent such code from being transported.
You might want to integrate the use of the SAP code inspector into your transport process.
See ya!
Thanks a lot Daniel for a valuable sharing.
I simply search with UNAME to avoid all concern in prior comment 🙂
Hi Daniel,
even though I like the post, I have seen many more “options” to hide and none of your examples to find such vulnerable code would have detected it.
Just one example out of many: write SYST-UNAME instead of SY-UNAME.
or use
ASSIGN struc TO…
ASSIGN COMPONENT 127 OF STRUCTURE TO…
whereas struc is of SYST.
Cheers, T1
Hey T1,
yep right – there are plenty of other ways to obfuscate hard-coded usernames. And when you think you got ’em all, there are probably still more… 😉
With my post I want to raise awareness for that topic – that’s why I didn’t even try to enumerate all possible ways.
Hope it still helps!
Best wishes, Daniel
Hi Daniel, nice post!
This unfortunately is something I see way too often when working with ABAP code, and it tends to end up in production regularly.
It’s easy to spot though if you use the Code Inspector as part of your development process (I always run the inspector before releasing something for transport).
You can detect the usage of sy-uname by creating a code inspector check variant (transaction SCI) and selecting the option ‘Search functions > Search of ABAP tokens’ and enter ‘*SY-UNAME*’ as one of the values. Make sure to check both ‘Comments’ and ‘Literals’ options.
It should even detect it inside obfuscated code like this:
Thanks René – that’s very helpful information!