WITH HEADER LINE – it’s not simply obsolete; it’s a risk.

shutterstock_424352977_akqw_jpgThe addition “WITH HEADER LINE” has technically been unnecessary going back several SAP versions now. This is because the statement declares both internal tables and an additional data object – the header line.

There are a large number of notes that spread awareness that the use of this statement causes various content problems. Among other things, the use of the same name means that it is not immediately apparent as to whether you are working on a table or a header line.

However, what the notes typically do not warn you about is that this kind of programming goes hand in hand with security problems for your SAP systems.

Despite everything, header lines can still be found in a great deal of program code. The typical argument is that using a header line is the only way to use short forms. That ensures that the structure to be added no longer needs to be specified explicitly.

Example:
SAST-Blog_Headerline_Abb01_1804_en

How this becomes a security risk to your SAP systems

SAP systems, too, have been capable of Unicode for a long time now, which allows other non-Latin scripts to be used. All scripts are considered equivalent and can be used in parallel. This means that a user cannot recognize whether the letter in SAP is in a Latin or Cyrillic script.

Moreover, all SAP versions have used the table “TRMAC” for many years now. This table is used to have SAP global macros available to shorten code.

If the three options (short form + Unicode-enabled + table “TRMAC”) are combined, it is now possible to effectively hide code.

For example, code is created in TRMAC that is similar to the short form. However, the first letter is replaced by its Cyrillic equivalent. Even experienced developers will not typically immediately notice the switch in code when viewing the TRMAC table with transaction “SM30”.

TRMAC
SAST-Blog_Headerline_Abb02_1804_en

Code
SAST-Blog_Headerline_Abb03_1804_en

Despite this, the program executes the macro and continues running without any visible errors:
SAST-Blog_Headerline_Abb04_1804_en

The only visible difference is in the editor: key words are color-coded, but macros are not. Many developers often consider key words that are not color coded as something to which no changes have been made, and thus they fall through the cracks.

Even if the corresponding code is searched using “APPEND”, you will find it only by copying the macro from the TRMAC table and pasting it into the search field. The best known internal table with a header line (which is still used today) is table SCREEN, in which you can edit dynpro fields before displaying them. The above example also works with this.

How to protect your SAP systems from hidden ABAP code

Use only code that is written correctly and avoid abbreviated versions. This means that the structure must be specified explicitly and more words will be included in the statement.

Ensure that definitions are required for additional variables. Developers are much more likely to notice variables named “FROM”, “INTO” or “TO” in their program code, especially if the advanced syntax check is performed:

SAST-Blog_Headerline_Abb05_1804_en

The use of the SCREEN table with the abbreviated notation has been obsolete since some SAP releases. Therefore, use the following syntax instead:
SAST-Blog_Headerline_Abb06_1804

MarkusRest
Markus Rest
SAP ABAP Development

Are you looking forward to further tips and recommendations in the field of SAP Security and Compliance? There are plenty of opportunities to engage with us – in one of our webinars, for example.