1 2 3 11 Previous Next


153 Posts

From the developer’s perspective


For AS Java, the encoding is available as tc_sec_csi.jar. There is a static class and an interface which provides the encodings for HTML/XML, JavaScript, CSS and URL. Also it is available to use methods of public class StringUtils (com.sap.security.core.server.csi.util.StringUtils):


  • escapeScriptEndTag(String pStr) - Prepare a string to be used for a javascript string definition with particular care about script tag;
  • escapeScriptEndTag(StringBuffer sb, String pStr)- Prepare a string to be used for a javascript string definition with particular care about script tag.
  • escapeSpace(String input) - Encode a space with + Note that this function will call 'disableScriptSignatures'.
  • escapeToAttributeValue(String input) - Encode a string for output as an attribute string of a tag, no URLs!
  • escapeToAttributeValue(StringBuffer sb, String input, int maxLength) - Encode a string for output as an attribute string of a tag, no URLs!
  • escapeToAttributeValue(String input, int maxLength) - Encode a string for output as an attribute string of a tag, no URLs!
  • escapeToHTML(String input) - Encode a string for output between tags (CASE1)
  • escapeToHTML(StringBuffer sb, String input, int maxLength) - Encode a string for output between tags (CASE1)
  • escapeToHTML(String input, int maxLength) - Encode a string for output between tags (CASE1)
  • escapeToJS(String input) - Encode a string inside a JS string declaration (CASE5)
  • escapeToJS(StringBuffer sb, String input, int maxLength) - Encode a string inside a JS string declaration (CASE5)
  • escapeToJS(String input, int maxLength) - Encode a string inside a JS string declaration (CASE5)
  • escapeToURL(String input) - Encode a string that represents a URL (CASE3) Note that this function will call 'disableScriptSignatures'.
  • escapeToURL(StringBuffer sb, String input, int maxLength) - Encode a string that represents a URL (CASE3) Note that this function will call 'disableScriptSignatures'.
  • escapeToURL(String input, int maxLength) - Encode a string that represents a URL (CASE3) Note that this function will call 'disableScriptSignatures'.
  • urlEncode(String s) - A trivial replacement of URLEncoder.encode
  • urlEncode(StringBuffer sb, String s, char[] forceEncode) - This is an extended version of the URLEncoder.encode method.
  • urlEncode(String s, char[] forceEncode) - This is an extended version of the URLEncoder.encode method.

CASE1 (Output BETWEEN tags)



CASE2 (Output INSIDE tags, but output is not a URL)


<form name="CASE2">
  <input type="text" name="user" value="[CASE2]">
  <input type="text" name="user" value='[CASE2]'>
<a name="[CASE2]">Click here</a>


CASE3 (Output is a URL)

<a href="CASE3" style="[CASE3]"><img src="[CASE3]"


CASE4 (Output inside a SCRIPT context, but output is not a string declaration)


var a = [CASE4];


CASE5 (Output is a string declaration in a script)


var a = '[CASE5]';


The class name is XSSEncoder (class name with package name: com.sap.security.core.server.csi.XSSEncoder).


The interface is IXSSEncoder(interface with package name: com.sap.security.core.server.csi.IXSSEncoder). The interface can be retrieved with com.sap.security.core.server.csi.XSSEncoder.getInstance().


The class XSSEncoder and the interface IXSSEncoder are the successors of the class StringUtils (see SAP Security Note 866020 [10] and its update Note 1601461 [11]), so the same dependencies have to be fulfilled, for example, a runtime reference to the J2EE library security.class or tc/bl/security/lib and a compiler reference to tc_sec_csi.jar.


Context Method

HTML / XMLout = XSSEncoder.encodeHTML( in ) and XSSEncoder.encodeXML( val );
JavaScriptout = XSSEncoder.encodeJavaScript( val );
URLout = XSSEncoder.encodeURL( val );
CSSout = XSSEncoder.encodeCSS( val );


For information about the delivery of these extensions, see SAP Security Note 1590008 [12].

WebDynpro Java


For WebDynpro Java, you do not have to care about XSS. The security is ensured through the framework itself.

SAP UI Development Kit for HTML5


For the SAP UI Development Kit for HTML5, the encoding functions are implemented as a jQuery plug-in in framework/_core/src/main/js/jquery.sap.encoder.js.


The functions to use for the different contexts are:

HTML / XMLjQuery.sap.encodeHTML(sValue) and jQuery.sap.encodeXML(sValue)

From the administrator’s perspective


The administrator has to set the parameters to improve security:

  • Global_app_config/session_config/sessionTimeout = 900. Enable session timeout to minimize potential attack window.
  • SystemCookiesDataProtection = true.  Declaring a cookie as HttpOnly increases the security of your system because it eliminates access to this cookie in the Web browser from client-side scripts, applets, plugins, and the like. Set httpOnly flag to secure cookies from transmitting them into the malicious host using XSS vulnerability.
  • ume.logon.httponlycookie= True. Logon tickets are cookies that are used for user authentication and Single Sign-On in J2EE Engine.  Value “True” means that the session information can be transmitted only by HTTP and obtaining of cookies using document.cookie (typical example of XSS attack) is not possible.
  • SessionIPProtectionEnabled = True. Specifies whether the session IP protection is enabled. When this property is set to true, the HTTP session cannot be accessed from different IPs. Only requests from the IP that started the session are processed.

From incident response perspective


To be able to identify the real attack happened because of the XSS vulnerability and also from some other web-based vulnerabilities, it is recommended to configure the following parameters.

  • LogCLF = TRUE in configuration file http.properties enables logging in CEF format.
  • ArchiveOldLogFiles = ON. The Log Configurator service provides an option for automatic archiving of log files. Logs are written into a set of files. When the last file is completed, the new logs start overwriting the old log files. If there is no archiving for access logs, all logs soon will be overwritten.
  • Enable Additional information logging [13].
  • HttpTrace= Enable. To enable HTTP Trace for more information run ConfigTool. Open the Properties tab of the HTTP Provider Service running on the dispatcher and assign the appropriate value to the HttpTrace property.

Last week we saw a conference talk and a few press articles related to an alleged default security configuration in SAP HANA installations.


We have thoroughly investigated these reports. Our recommendation to all of our customers is to follow the advice in the SAP HANA Security Guide and change the default master keys that are issued with SAP HANA installations. More information can be found in SAP security note 2183624 (registration required).


SAP stands for secure and reliable software solutions. As a global leader in business software, we take customer security very seriously and implement a high degree of product safety. Confidentiality, integrity, availability and data privacy are core values for SAP and its customers.


SAP has a comprehensive product security strategy across the enterprise that rests on three pillars: “Prevent – Detect – React”. An important component of this strategy is the "Secure Software Development Lifecycle" (S²DL) which provides a comprehensive framework of processes, guidelines, tools and staff training. Thus, we are able to ensure that security is an integral component when it comes to the architecture, design and implementation of SAP solutions.


We are continuously looking for ways to ensure customers’ systems are secured by improving our solutions, informing customers about recommended precautionary steps and providing security, data privacy and data protection services and products to our customers - for details see sap.com/security.

We continue our series of posts giving a review of one of the most frequent vulnerability which affects a lot of SAP modules: cross-site scripting, or XSS. Today's post describes how to protect SAP NetWeaver ABAP from XSS.


From the developer’s perspective


For all generic Web applications where you accept input parameters, you must use encoding methods provided by the ICF handler. The implementation of the encoding is available as an API in two variants:

  • ABAP built-in function ESCAPE (available as of SAP_BASIS >= 731);
  • Class implementation in CL_ABAP_DYN_PRG.

In releases higher or equal to SAP NetWeaver Release 7.0 enhancement package 3 (SAP_BASIS >= 731), use the ABAP built-in function ESCAPE(). For more information, see the ABAP keyword documentation for the ESCAPE() function.


HTML / XMLout = escape(val = val format = cl_abap_format=>e_xss_ml).
JavaScriptout = escape(val = val format = cl_abap_format=>e_xss_js)
URLout = escape(val = val format = cl_abap_format=>e_xss_url)
CSSout = escape(val = val format = cl_abap_format=>e_xss_css)


For lower releases (SAP_BASIS 702, 720 and below), there is an ABAP OO implementation. The implementation is in class CL_ABAP_DYN_PRG.




For more information about the delivery of these extensions, see SAP Security Note 1582870 [1].

For WebDynpro ABAP 


For WebDynpro ABAP, you do not have to care about XSS at all. The security is ensured through the framework itself.

For Business Server Pages (BSP)


For BSP, you should use the page directives. For more information, see SAP Security Note 1600317 [2] and SAP Security Note 1638779 [3]. These BSP page attributes have the advantage that the BSP framework ensures that the most secure version of encoding is used.


For BSP, you should use the page directives: <%@page language=“abap“ forceEncode=“html|url|javascript|css“%>


After importing SAP Security Note 1600317 [4], the existing page directives also use the updated BSP compiler that supports HTML encoding of all print statements on the page.


In the following example, all print statements use HTML encoding. It only affects print statements on BSP pages and does not have anything to do with tag parameter passing that uses the same syntax, but has different semantics.


BSP example:
<%@page language=“abap“ forceEncode=“html“%>
  <% data: inputvalue type string.
  inputvalue = request->get_form_field( 'x' ).
  <input type=text name=x value=“<%=inputvalue%>“>
  <input type=submit>


The global page attribute defines the default encoding used within the page and all included page fragments. Besides the global page attributes, you can use the following notations for controlling the encoding behavior of a special print event (overriding the global settings):

  • <%html=...%>: HTML encoding
  • <%url=...%>: URL encoding for parameter names or values of URLs
  • <%javascript=...%>: JavaScript encoding
  • <%css=…%> : CSS encoding
  • <%raw=...%> (no encoding, that is, a global encoding that was set in the page directive is switched off)


Using forceEncode within a page directive in a page fragment has no effect. The encoding within page fragments is always controlled by the including page.

For BSP Online Text Repository (OTR)


One aspect that is similar to an XSS attack is a translation-related change that breaks the HTML or JavaScript code.

  var msg = '<otr>Hello</otr>';
  <input name=xyz value=“<otr>Replace 'dog' with


Therefore, there is an extra page attribute that you can set. When this attribute is set, all OTR texts are effectively encoded directly after they have been retrieved in their language-dependent form.


For BSP ORT, you should use the page directives:
<%@page language=“abap“
forceEncodeOtr=“html|javascript“%> HTML example
<%@page language=“abap“ forceEncodeOtr=“html“%>
<script>   var msg =

JavaScript example
<%@page language=“abap“ forceEncodeOtr=“html“%>
var msg = '<%JavaScript=<otr>Hello</otr>%>';

For BSP Extensions

For the BSP HTMLB library, you must set the attribute forceEncode of the <htmlb:content> tag to ENABLED to switch on the internal encoding because it is set to disabled by default. ENABLED means that the extension will use an appropriate encoding depending on the context within a value is used:
<htmlb:content forceEncode=“ENABLED|BACKWARDS_COMPATIBLE“>


  • ENABLED: This means to always encode everything. This overwrites all other encode attributes and they no longer have to be set;
  • BACKWARDS_COMPATIBLE: This is the default value. The usual encode attributes are active as previously defined.


In addition, the attribute design of htmlb:content specifies the possible designs as a page supports. Valid values are CLASSIC, DESIGN2002, DESIGN2003, or DESIGN2008, or combinations separated by a plus + sign. The older designs CLASSIC and DESIGN2002 are no longer supported (and possibly insecure) and are therefore not to be used anymore:
<htmlb:content forceEncode=“ENABLED“ design=“DESIGN2003+DESIGN2008“>


If you do not specify a design, then design=CLASSIC is used. Therefore, we recommend overriding this default with one of the supported designs mentioned.

Mixed BSP page with HTML and HTMLB tags


The attribute forceEncode of the BSP page directive @page and the attribute forceEncode of the HTMLB content tag are independent of each other. The first one controls the encoding of variables outside any extension, whereas the last one controls the encoding with the extension HTMLB. Therefore, for a mixed page using HTML in combination with BSP Extensions, you must set both parameters as described in the sections above.
<%@page language=“abap“ forceEncode=“html“%>
  <htmlb:content forceEncode=“ENABLED“>
  <htmlb:textView text=“<%=param%>“/> (1)
  <%=param%> (2)


In this example, the encoding of the variable param in line (1) is controlled by the forceEncode attribute of the htmlb:content tag, and the param in line (2) is controlled by the forceEncode attribute of the page directive.

The BSP encoding directive <%url|html|javascript=...%> has no effect when passing values to attributes of extension tags and is simply ignored.

In the following example, the directive to do HTML encoding is ignored, instead of the htmlb tag decides internally which encoding is appropriate.
<htmlb:content forceEncode=“ENABLED“>
  <htmlb:textView text=“<%html=param%>“/>

For Internet Transaction Server (ITS) and HTML Business


For the Internet Transaction Server (ITS) and HTML Business, the following encoding functions are available:

  • xss_url_escape()
  • xss_html_escape()
  • xss_wml_escape()
  • xss_css_escape()
  • xss_js_escape()

HTML Business


When addressing values of variables using the HTML Business notation: that is, using back quotes (`) or the <server> delimiter, the encoding is controlled by the global parameters:


  • ~auto_html_escaping=1: globally activates encoding
  • ~new_xss_functions=1: globally activates the use of the updated XSS library


This can be overruled locally in the templates by setting the parameter ~html_escaping_off=1/0 in order to switch off or turn on the escaping.


Where and how these parameters are specified depends on the SAP_BASIS release:

  • For the external ITS (Release <= 6.40), maintain them in the properties of the Internet Service in SE80.
  • For the internal ITS (Release >= 6.40), maintain them in the GUI properties in transaction SICF as follows:
    • Release 6.40-7.11: ~auto_html_escaping=1 and
    • ~new_xss_functions=1 o Release >=7.20: ~auto_html_escaping=1


As of Release 7.20, there is no need to set the parameter  ~new_xss_functions as the updated XSS library is used in all cases.


You must thoroughly test the application when using this approach because there may be cases where the encoding is too generic and can lead to false encoding. In such cases, you can use set the parameter ~html_escaping_off=”X” to deactivate the automatic encoding and manually call the functions named. For more information, see SAP Security Note 1488500 [5].

For Business HTML (BHTML)

The functions of the HTMLBusiness Template Library (for example SAP_TemplateNonEditableField()) always properly encode and cannot be switched on or off. For more information, see SAP Security Note 916255 [6].

For Manual Encoding

You can also manually encode output by using the functions named above. In this case, encode all output.

From the administrator’s perspective


The administrator has to set the parameters to improve security:

  • http/security_session_timeout = 900; Enable session timeout to minimize potential  attack window.


  • icf/set_HTTPonly_flag_on_cookies = 0; Declaring a cookie as HttpOnly increases the security of your system because it eliminates access to this cookie in the Web browser from client-side scripts, applets, plugins, and the like. Set httpOnly flag to secure cookies and Logon Tickets from transmitting them into the malicious host using XSS vulnerability.


To change the parameter activate the RZ10 transaction, select (in the field Profile) necessary profile (for example DEFAULT.PFL if the parameter should be applied globally for the SAP system). To create, change or delete the parameter in a profile select <i>Extended maintenance</i> and press the change button. When changes are made, select the Copy button.

From incident response perspective


To be able to identify the real attack happened because of the XSS vulnerability and also from some other web-based vulnerabilities, it is recommended to configure the following parameters.


  • Configure  icm/HTTP/logging_0 parameter
    • set LOGFILE value  to path_to_file
    • Sеt PREFIX value to “/”. If URL prefix=“/“  (root directory), or empty which means that all HTTP requests will be logged. If prefix value equal “/Directory“, the server will log only requests which call “/Directory“ directory and subsequent.
    • Set FILEWRAP value to  off. Old log files will be saved for future analysis


  • Configure icm/security_log parameter, o set LOGFILE value  to path_to_file
    • set VERBOSITY value to 3. To be able to save all necessary data in
    • Set FILEWRAP value to off. Old log files will be saved for future analysis

SAP enterprise threat detection is a HANA based SAP Solution that can monitor and correlate data from disparate SAP and non-SAP systems in the IT landscape and hence can help manage exposure to internal and external threats. The business case behind this product and the solution brief can be found on the following link.SAP Enterprise Threat Detection.This blog lists the components of the ETD solution,the integration between these components and describes the configuration steps to be performed to make an ETD system ready for usage.


Components :The ETD solution has 3 components

  1. HANA component (delivery unit that is imported into the HANA system).
  2. ESP component (Event stream processor), which acts as an interface between the HANA system and the target system from which logs are being collected.     
  3. Target system component . The target can be a SAP or a non-SAP system ( In this blog post, the target system is assumed to be a SAP ABAP system)


Configuration steps

Step 1: Importing the delivery unit


1. Import the delivery unit into your HANA system. (If you receive error/s , while importing  the file , you need  check the HANA version compatibility with the delivery unit as the required HANA version can vary based on the SP level of the delivery unit ). HANA ALM can also be used for importing the delivery unit. The delivery unit to be imported is available on the SAP Service Market Place.




Before the actual import a simulation is performed, as shown below.



Step 2: Set up ESP and HANA Connectivity

The  ESP projects enhance and enrich the content of the logs that are obtained from the target system.


Prerequisites: ESP should be installed. The installation process is fairly simple and details can be found on the ESP installation page. ESP Installation can be on a Linux or a windows machine. The configuration steps shown on this blog are relevant when ESP has been installed on a windows instance.


Once ESP is installed, connectivity between the HANA system and SAP ESP can be set up and this is done via an ODBC connection.

a) Create ODBC connection

    On the windows machine, ( where ESP is installed)  go to the start menu and search for ODBC and choose "data sources" as shown below.




Fill up values in fields: Data Source name and Description



While creating the ODBC connection, just copy the information from the “Additional Properties” section in the HANA Studio. Full path

HANA Studio => Server =>Right click and Properties => Database User Logon => Additional Properties


Provide user name and password for the HANA system and choose connect.


b) Create the Data Service

    On the ESP studio, navigate to data services view


Select the server node and choose ad ODBC service



Right click and choose discover


c) Importing ESP projects

ESP projects are delivered as part of the HANA delivery unit. As a precursor to importing the projects into the ESP studio the esp folder must be checked out ( as shown below ) followed by placing the the contents of the ESP folder ( that also contains the ESP projects ) to a location which is accessible to the ESP studio.



Once the projects are accessible , they can be imported into the ESP studio as shown below.Files to be imported  are transfer_log.zip and transfer_master_data.zip.





d)   Start the SAP ESP web service provider

Use the esp_wsp.bat file, path C:\esp_rootpath\wsp\esp_wsp.bat



Step 3) Configure the Target system

ETD related corrections and reports are delivered with SAP_BASIS 7.4 SP10. However if upgrading to the required release and SP is not an option,individual notes can be applied manually.Once this perquisite is met, following steps are to be followed.

a) Configure report SECM_CONFIGURATION

     Transaction SE38 = > Program SECM_CONFIGURATION



In the SECM: Configuration report, navigate to the second tab and provide login details of the adm user of the Netweaver system.



c) Transfer logs from ABAP system to ESP server

      Execute report: SECM_LOG_2_ESP



In case there are issues, following SQL queries can be executed to check if logs have been pushed properly to the HANA system .


Log header: select * from "SAP_SEC_MON"."sap.secmon.db::Log.LogHeader"

Log detail: select * from "SAP_SEC_MON"."sap.secmon.db::Log.LogDetail"


To view the ETD home page, launch the url



Alerts can be browsed from the alerts section: Highlighted below


ERPScan's team core purpose is to take the definition of the SAP security one step further by providing its own guidelines to help SAP users carry out various security checks. We have covered :

  • 9 the most important business application security critical issues [1],
  • patch management flaws [2],
  • default passwords for access to the application [3],
  • unnecessary functionality [4],
  • open remote management interfaces [5],
  • security settings that do not fit into any of the critical issues groups [6],
  • Access control and SOD conflicts [7],
  • Unencrypted connections [8].

Today, we'll turn our attention to the next critical issue, which is the last one of all but not the least important.

One of the most important aspects to ensure the SAP security (and of any other critical system) is security event logging in place. In case of an incident (which is likely to happen because there are a plenty of settings in such systems and it is quite difficult to control all of them), only the security audit configured correctly will allow the company to discover the fact of an attack in time and, perhaps, to arrange a response to it. Besides, the security audit configured correctly allows to prevent attack in the early stages of collecting system data.

Security event logging system is complicated with a lot of different logs for each SAP subsystem, with each of them able to store sensitive information. Unfortunately, few of these logs may be centrally analysed. This section contains four most critical logs.

Further steps

In total, the SAP system contains about 30 critical and trace logs (for ABAP instance only). After enabling four basic logs described below, implement the fine-tuned settings, e.g., detailed table lists with enabled table logging, details of security event logging in security audit logs, detailed event types in the SAP Gateway log, etc. Also, their central collection and storage implementation should be accompanied with critical events analysis. Only then, you may add and analyse more detailed optional logs for each service.

[EASAI-NA-30] Logging of security events


The SAP security audit log is an addition to the system log, but with a slightly different purpose. In contrast to the system log that must be always active, a security audit log may be enabled and disabled if required. The security audit log is a tool for a detailed overview of all events in a SAP system. The main audit log purpose is to record:

  • security-related events in the SAP system neighbourhood (e.g., modifications in primary user accounts);
  • information to make system more transparent (e.g., successful and invalid system logon attempts).
  • information to reconstruct a chain of events (e.g., successful or failed transaction start).

Filters are used to determine what information should be recorded in the audit log file. In case of event that meets active filter criteria (e.g., start of a transaction), the audit log generates an audit message and writes it to a file. Also, an appropriate notification will be sent to the CCMS Alert Monitor (SAP Computing Center Management System Alert Monitor) used to observe centrally the ABAP and Java components, reveal various categories of system and application errors in different interfaces. A detailed information on events is presented in the auditor's report on the audit log vulnerability assessment. Using filters, you may specify actions needed to be recorded with SM19 transaction. To review the log, SM20 transaction is used. SM18 transaction allows removing old logs. The audit files are located at individual application servers. You may specify the file location and the maximum file size in the following profile parameters. The basic parameter is rsau/enable, which enables the audit log on the application server and by default is set to: 0 (inactive audit);


If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential external attacks or internal fraud. An opportunity to carry out the Forensic Investigation after the fact of hacking is almost fully excluded, too.


It is necessary to set the rsau/enable parameter to “1” (enable) to enable the security event logging. Then, it is necessary to configure filters by specifying exactly what events should be monitored using the SM19 transaction.

[EASAI-NA-31] Logging of HTTP requests


If the ABAP application server is used for web connections by the ICM service, then it is necessary to configure logging of the HTTP requests to the ABAP application server. The icm/HTTP/logging_<xx> parameter is used to manage the HTTP-requests logging in the ICM service (or web dispatcher), if the ICM operates as a server. This parameter defines if HTTP-requests logging is enabled for the ABAP sources. If the ICM acts as a client, you may use the icm/HTTP/logging_client_<xx> parameter for the HTTP logging. The icm/HTTP/* parameter set is valid for the HTTPS as well. The parameter syntax looks the following way: icm/HTTP/logging_<xx>=PREFIX=<URL prefix>, LOGFILE=<log file name> [LOGFORMAT=<format>, FILTER=<filter>, MAXSIZEKB=<size in KBytes>, SWITCHTF=<options>, FILEWRAP=on] The LOGFILE parameter value determines the output file name in the file system. The HTTP-requests logging is not executed if the LOGFILE value is not specified.


If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential attacks with the HTTP protocol use. These logs are highly critical, in case the ICM service has the Internet access. Forensic Investigations of an incident related to the Internet attacks is almost impossible with these service logs disabled.


Specify the OS file name in the icm/HTTP/logging_<xx> parameter in the LOGFILE value to collect all necessary information on potential attacks. It is essential for a Forensic Investigation.

[EASAI-NA-32] Logging of table changes


All SAP data are presented in tables. There are two different table categories:

  • Client tables. They contain data used for one client (mandant) only, e.g., the user system logon data in USR02.
  • Cross-client or client independent tables. These contain data valid for all the system clients, such as, for example, the T000 table.

The SAP provides table modification logging option to determine what a user has changed, added or removed in the data from tables and when. There are two technical requirements; with both of them in place, you may be sure that table modifications are logged:

  • the general logging should be enabled;
  • the technical table parameters should be set to "Record data changes".

The data recorded for these modifications is stored in the DBTABLOG table (DBTABPRT in lower versions). For them, the BC_DBLOGS archiving object may be used.

General logging The table changes are not logged by default. Activate the associated settings for the selected clients through the rec/clientsystem parameter. This parameter may have the following values:

  • OFF (disabled logging),
  • All (logging is enabled for all the system clients),
  • <Client number>, (...) (logging for clients with the numbers filled in here).

This parameter covers only those table modifications that result from direct system changes. The modifications occurred as a result of transport activities (for example, import) do not interact with this parameter ("Logging through transports" is used for this).

Warning!: the changes are not recorded when copying client.

Table logging The table logging is controlled by an appropriate value in the technical table configuration (for display, the SE13 transaction is used). To review all the tables logged, the DD09L table is called with the SE16N transaction. It works with the tables where:

  • the maximum number of characters in the key field is 250;
  • the maximum number of character in the data fields is 3500;

Transport logging To log modifications resulted from transport activities, set up the associated transport parameters. These parameters may be enabled in the Transport Management System (TMS) with the STMS transaction. The desired values for the transport profile (All, <Client number>) are set in the recclient parameter (see SAP Security Note 163694 [9]).


With no direct table access logging, there is a risk of late or no response to potential unauthorized table data modifications, e.g., an adversary may change the bank account value in the LFBK table and commit fraud actions by money transfer to another account.


  • You should change the rec/client parameter to values corresponding to all production client numbers to collect all required information for a potential Forensic Investigation.
  • Automatic logging is not recommended in test systems, as this may lead to a very rapid disk space fill.
  • You should log all specific tables with all transaction, system control, setting and other main data, as well as all the data where logging is under question.
  • For production system, you should log all clients (rec/client = ALL), at least those of production. But if you set the rec/client parameter to ALLyou may seriously affect the system performance.
  • For more information, see the following notes: 1916, 112388, 84052. [10] [11] [12]

[EASAI-NA-33] Logging of SAP Gateway activities


Each SAP instance has the SAP Gateway. The gateway ensures interaction between work processes and external programs, and also interaction between the work processes from different instances or SAP systems. The gateway allows to execute RFC services at a SAP system. Higher security requirements are applied to a gateway since it is an application server interface with other systems (other SAP systems, external programs, etc.), one of these requirements is gateway logging activation. The gateway logging is used to control the gateway activity. You may configure what gateway actions exactly will be recorded in the log file. It is possible to configure the log maintenance in the gw/logging parameter or in the gateway monitor (the SMGW transaction). Notice that the gateway monitor is not available if a separate gateway or the Java-only installation are used. The parameter gw/logging contains various indicators that are responsible for logging of certain event types. The S indicator (i.e. Security) in the ACTION field is the most important allowing to record security configuration events and their modifications (e.g., file reloading), with other event types being also important.


With no security event logging, there is a risk of late or no response to potential attacks on a gateway. The risk of a security breach is considerably increased by this service vulnerabilities known since 2007 and exploits available on the Internet and that enables to get unauthorized access to the service and execute any OS commands.


  • Add S value to the ACTION field for the gw/logging parameter to increase the security level and gain all information required for the potential Forensic Investigation.
  • Logging of other security event types is also advisable.


Below blog can we divided in two parts. First part is our initial approach where we faced certain challenges as stated below. Second part is the final solution we gave to client which worked perfectly since then.


Recently we got a requirement to generate a report of "Failed Logon Attempts" for our client. This report was requested by client for audit purposes.


The first thing that striked our mind as a solution was to use custom report view in SAP Netweaver Administrator.


So we logged in to http://<domain name>:50000/nwa

Portal Logon Screen.jpg

We navigated to Troubleshooting -> Logs and Traces -> Log Viewer

In the default view we got all the logs.

Now our requirement was to create a custom log view that is specific to our needs i.e. to get Failed Logon Attempts.


We analysed how does typical log of failed logon attempt looks like.

We went to server directory and fetched one log record with Failed logon attempt. The same I am posting below.


#1.5#00199983C074009A0000C86100006FB10005054DFD4E42D9#1413207403938#/System/Security/Audit#sap.com/com.sap.security.core.admin#com.sap.security.core.util.SecurityAudit#Guest#0##n/a##f88fd67152dd11e4cb5a0000002e2bba#SAPEngine_Application_Thread[impl:3]_6##0#0#Warning#1#com.sap.security.core.util.SecurityAudit#Plain###Guest      | LOGIN.ERROR                | null     |              | Login Method=[default], UserID=[z******3], IP Address=[**.**.**.**], Reason=[Authentication did not succeed.]#


The key in above log for us was the keyword "LOGIN.ERROR"

So we created a custom view in NWA Log Viewer utility for us by selecting view->open view-><create new view>

Create new view context menu.jpg

Our new report view was having few parameters specific to our needs as below

Custom log view parameters.jpg

Main parameter was "LOGIN.ERROR" which would filter records for us on "Failed Logon attempts". This is exactly what client wanted.

Once we run this report it correctly displayed log records for us.

We could either download them in Excel or send a snapshot to client.

Custom report Output.jpg


But things never turned out to be that simple for us as we were facing certain challenges with above report:

A major challenge that we faced was, this report sometimes returned us "No records to Display" for a particular date range. But after couple of days it used to work correctly for the very same date range. This we raised with SAP and they correctly reverted back that we need to upgrade our SP level.

Few other challenges were :

1. We did not had any further control on customization level of report. As client had to interpret the entire string of "message" column to get user id, address and reason text.

| LOGIN.ERROR                | null     |              | Login Method=[default], UserID=[zg****3], IP Address=[**.**.**.**], Reason=[Authentication did not succeed.

2. When we opted to export this report on excel again we never received output, that too might be due to our SP levels.

3. This report used to take long time to execute.

4. These logs gets archived and are transferred to another directory on server, as a result out custom report in NWA would always fetch empty log records for archived date range. Sometimes client requested old log records as well. Though there is a "archive" view in Log viewer, but again it took ages to execute and also fetched empty records for us ... of-course due to our SP level.


So due to above challenges we started thinking about an alternative approach.

One thing I would like to add here is that we had access to server directory structure where all log files were physically stored.


So I came up with an idea to create a custom Java application that takes these log files as input and produces a Excel report as per our needs as output.

This now brings me to Part 2 of this article - The actual solution.


The process that we followed going forward to generate reports was :

Step 1 : Basis/Security team use to get those log files from server and mail them to me, or share on our corporate directory which I have access to.

Step 2 : I get those log files and place them in my local folder, unZip them if required.

Step 3 : I execute Java program that takes these files as input and generate a excel report for me in only 2-3 seconds !!!

Step 4 : I mail that xlsx file back to Basis/Security team which they shares with client.


The Java Solution

I would only provide code snippets below, and if you have similar requirement, you can ask any Java developer to create a similar class for you as per your specific requirements.


I used Eclipse as development IDE.


Code snippet 1:

In below snippet I specified the root directory which would contain all log files.

Code Snippet 1.jpg

My directory structure looks like below :

Local file structure.jpg


Above code snippet access this directory structure.

In my case I only kept 1 level deep directory structure.

you can use recursion to have multiple nested directories.

We got list of all directories from below code

Code - get list of files.jpg


Code snippet 2 :

We specified an output file where our actual processed report will be saved.

Code Snippet - output filename.jpg

We used Apache POI APIs to generate our Report.xlsx file.

Code Apache POI.jpg


Above code snippet shows that we created a Excel workbook with a sheet "UME Report".

This sheet will contain a table of five columns "Date, Time, UserId, IP Address, Reason".


Code snippet 3


In below snipped I have traversed all files one by one in all directories within my root directory.

Code - Traversing the list of files all  directories.jpg

Code snippet 4

Once I get the files I am using below code to fetch those files line by Line.

Traverse file line by line.jpg

Once I get a log record which contain LOGIN.ERROR I fetch all required information from that log record and process them.

Process LOGINERROR log.jpg

Since timestamp in our case was in UNIX format terefore we formatted it as per our requirements.

Process date.jpg

process timestamp.jpg


Code snippet 5


Once all information is processed I inserted that in excel using Apache POI APIs.

insert in apache poi.jpg

and finally excel file is generated

generate excel file.jpg


The generated Excel file looks like below :

excel file.jpg

In our previous article we’ve already covered how SAP ABAP Security Storage works. Today’s post is dedicated to SAP HANA Security Storage.

SAP HANA is a recent key product of SAP. It is a software solution based on the in-memory technology, that reduces the time of the data processing significantly.


This product has obviously caused an excitement among large enterprises interested in processing their data in real time. We do not doubt that SAP HANA is capable of processing big data. However, the security of critical data companies stored in SAP HANA deserves attention.


The HANA platform is shipped with equipment (hardware platform with pre-installed SAP HANA software) provided by such vendors as HP, IBM, Del, Hitachi, Fujitsu, and Cisco. HANA is also available as a cloud solution (called HANA One) from several cloud service providers like Amazon and Microsoft Azure.



So, what encrypted  data are stored in SAP HANA, where are they stored and, above all, how secure are they ?


Let’s look at SSFS_  < SID>.DAT file, where   < SID> is an identifier of SAP HANA.



This file can contain the following information:

  • User data (login, encrypted pass),
  • Encrypted Root key,
  • Encrypted other keys.


As you can see, there are user passwords. It’s what an attacker is searching for!


3DES is used as an encryption algorithm. And it’s the key that have some issues. By default, SAP HANA uses the same key for encryption as ABAP Security Storage, and, as a result, the key is the same for all SAP HANA systems.


With access to the encrypted storage (file SSFS_.DAT), nothing prevents an attacker from stealing the data that this storage contains.



Besides user passwords, an attacker, for example, can get access to the root key. The eponymous database called SAP HANA is an in-memory solution, which means that all data are processed in random-access memory of a server that, for instance, does not allow an attacker to simply copy the database file and access the data. However, as it turns out, HANA uploads data to the disk as a backup.


“The SAP HANA database holds the bulk of its data in memory for maximum performance, but it still uses persistent disk storage to provide a fallback in case of failure. Data is automatically saved from memory to disk at regular savepoints. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has completed., After a power failure, the database can be restarted like any disk-based database and returns to its last consistent state,”  – says SAP HANA Security Guide.


An attacker seems to be able to access the data from these backups. To prevent it, SAP has implemented disk encryption.

“Data volume encryption ensures that anyone who can access the data volumes on disk using operating system commands cannot see the actual data. If data volumes are encrypted, all pages that reside in the data area on disk are encrypted using the AES-256-CBC algorithm. After data volume encryption has been enabled, an initial page key is automatically generated. Page keys are never readable in plain text, but are encrypted themselves using a dedicated persistence encryption root key.” – SAP HANA Security Guide.


But try to guess where SAP HANA stores these keys. You are absolutely right, in the following fields of SSFS_  < SID>.DAT file:


“SAP HANA uses SAP NetWeaver SSFS to protect the root encryption keys that are used to protect all encryption keys used in the SAP HANA system from unauthorized access.” – SAP HANA Security Guide



Thus, with access to protected storage, an attacker can also gain access to the encrypted SAP HANA disk and, as a consequence, compromise sensitive data stored in the database.



  • Change SSFS master key using the rsecssfx tool
  • Change Data volume encryption root key using the hdbnsutil tool
  • Change Data encryption service root key using the hdbnsutil tool
  • Monitor your SAP system regularly for various vulnerabilities and misconfigurations to prevent attackers from accessing your database.


1) SAP HANA Security Guide

2) All your SAP Passwords belong to us

There is the list of themes we have covered in previous articles:

  • 9 the most important business application security critical issues [1], 
  • patch management flaws [2],
  • default passwords for access to the application [3],
  • unnecessary functionality [4],
  • open remote management interfaces [5],
  • security settings that do not fit into any of the critical issues groups [6],
  • Access control and SOD conflicts [7].

Seventh critical issue in SAP Security landscape: Unencrypted connections. To protect connections between the SAP NetWeaver system components, especially against the man- in-the-middle (MITM) attacks, it is necessary to ensure SAP security at the transport level. While using the Transport Layer Security (TLS), the data transmission may be protected from eavesdropping not only with encryption, but also with the partner authentication.

TLS provides the following types of protection:

  • Authentication: Communication partners may go through authentication. The server is always authenticated, while the client is authenticated depending on the algorithm.
  • Data integrity: Message exchange is protected so that any modification is revealed.
  • Data confidentiality: The data transmitted between the client and the server is encrypted, thus confidentiality is ensured. Eavesdropper is not able to get access to the data. Protection is available for inbound and outbound connections.

There are two forms of protection, depending on the used connection type. For connections using the Internet protocols such as HTTP, Secure Sockets Layer (SSL) protocol is used. For the SAP protocols such as RFC, Secure Communications Network (SNC) is used.

Further steps

This section contains the detailed encryption settings for various services. However, you should understand that, even if the encryption is enabled, it does not necessarily mean that it is always securely configured. For each type of encryption, in each particular case there are various settings to be fine-tuned. For example, recent BEAST and CRIME attacks on the SSL showed that more SSL fine-tuned settings are necessary [8]. That is why you should be very careful careful while configuring encryption, considering new attack types and peculiarities of the service.

[EASAI-NA-25] The SSL encryption to protect HTTP connections


SSL supports the following protocols:

  • HTTPS from HTTP,
  • IIOPSEC from the IIOP,
  • P4SEC from the P4.

Note that we take into consideration only the HTTP, as IIOP and P4 belong to the JAVA stack. In the ICM service parametericm/server_port_<xx>, the protocol and the port are specified, where <xx> is the ordinal number of parameter. This parameter is used to specify the service name or port number to be applied to by the protocol. Also, additional service properties can be defined. But one port cannot have more than one service assigned to it. Besides, the service can not start when another program is already using this service or port. Parameter line has the following syntax: PROT = <protocol name>, PORT = <port name> [, TIMEOUT = <timeout>, PROCTIMEOUT = <proctimeout>, EXTBIND = 1, HOST = <host name>, VCLIENT = <client SSL Verification>, SSLCONFIG = ]. Mandatory to be defined are the following parameters: protocol name (PROT) and service name or port number (PORT), other parameters are optional. Default system values for this parameter depend on the system type which is specified by the system/type parameter. The following types are available:

  • Double stack: system/type = DS (currently out-of-date). The instance contains AS ABAP and Java AS application servers:
    • icm/server_port_0=PROT=HTTP,PORT=5$(SAPSYSTEM)00,TIMEOUT=60,PROCTIMEOUT=600
    • icm/server_port_1 = PROT=P4,PORT=5$(SAPSYSTEM)04
    • icm/server_port_2 = PROT=IIOP, PORT=5$(SAPSYSTEM)07
    • icm/server_port_3 = PROT=TELNET,PORT=5$(SAPSYSTEM)08,HOST=localhost
    • icm/server_port_4 = PROT=SMTP,PORT=0,TIMEOUT=120,PROCTIMEOUT=120
  • Java only: system/type = J2EE (not covered by this document). The instance contains the Java AS application server only.
  • ABAP only: system/type = ABAP. The instance contains the ABAP (AS ABAP) application server only.
    • icm/server_port_0 = PROT=HTTP,PORT=0,TIMEOUT=30,PROCTIMEOUT=60
    • icm/server_port_1 = PROT=SMTP,PORT=0,TIMEOUT=120,PROCTIMEOUT=120



If there is no encryption of network connections, this can lead to unauthorized access to the data being transmitted by means of interception. HTTP protocol transmits all authentication data as a plain text, that allows to intercept it easily using the spoofing type of attack.


For HTTP connections, you should configure SSL. Detailed step-by-step instructions for this process may be found in the paper SSL Configuration in SAP ABAP AS and JAVA AS – Step-by-step procedure [9].

[EASAI-NA-26] The SNC encryption use to protect the SAP GUI client connections


SNC (Secure Network Communications) is a software layer in the SAP solution architecture. It supplies secure interface for external products. In particular, it is responsible for encryption and authentication. SAP solutions contain basic security controls including password-based user authorization and authentication concepts. With SNC in place, the SAP security can be improved by implementing additional security functions. Those functions are not provided openly by SAP solutions. It is, for example, the use of smart cards for user authentication, additional digital and encryption certificates. There are three security levels that can be applied. snc/data_protection/use parameter is responsible for this (by default it is set to 3 and shows standard connections protection level). Respectively, snc/data_protection/max and snc/data_protection/min show maximum/minimum protection level. So, those values show:

  • Authentication only (snc/data_protection/use=1). The system authenticates communication partners. It is the minimum security level provided by the SNC. Data protection is not ensured!
  • Integrity protection (snc/data_protection/use=2). The system detects any data modifications (manipulations) that may occur between the two communication endpoints.
  • Data confidentiality protection (snc/data_protection/use=3). The message encryption system makes the eavesdropping useless. This level also includes the data integrity protection. It is the maximum security level provided by the SNC.This level also includes data integrity protection.


The snc/enable parameter defines whether the SNC protection is used for connections.

  • The default value is: 0 (inactive SNC).
  • The secure value: 1 (active SNC)

As soon as the SNC is active (snc/enable = 1), the system starts accepting the SNC-protected connections only. If there is a need to accept a normal connection which is not protected by the SNC, it is necessary to set the appropriate parameters (snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/accept_insecure_cpic) depending on the types of connections to be accepted insecurely.


If there is no encryption of network connections, this can lead to unauthorized access to the data being transmitted by means of interception. HTTP protocol transmits all authentication data as a plain text, that allows to intercept it easily using the spoofing type of attack. If SNC encryption is not set, this can lead to unauthorized access to data transmitted between the systems using DIAG and RFC protocols. those protocols do not use data and passwords encryption, they use insecure compression algorythms. It is quite easy to decode those algorythms using free tools available on the Internet. This, in turn, allows to intercept passwords and get unauthorized access to system.


Set the snc/enable parameter to 1 to enable encryption, thus mitigating the risk of unauthorized access. Besides, the SNC User's Guide [10] recommendations may be useful here.

[EASAI-NA-27] The SNC encryption to protect RFC connections between systems


SAP systems can connect to the other SAP systems, or non-SAP systems using two basic methods:

  • by the Internet Communication Framework (ICF) that allows to use the HTTP, HTTPS or SMTP, or
  • by the Remote Function Call (RFC) which may be called directly in the system.

RFC is the SAP own interface necesary for integration of SAP system and non-SAP system software. RFC calls a function to be executed in a remote system. Other integration technologies, such as web-services, are optional in RFC. Currently, there is a whole range of various RFCs, each of them with various properties and used for specific purposes. To ensure security of RFC connections, a wide range of measures can be implemented, but in this article we describe encryption only.


RFC-functions called for via RFC protocol may transmit confidential data (e.g., passwords or payment card numbers). When using RFC without encryption, there is a risk that this data will be available as a plain text. If SNC encryption for RFC connections and SSL encryption are not used for HTTP connections between the ABAP-based systems, it makes it possible for an intruder to get access to sensitive data by intercepting it with a spoofing attack.


It is recommended to carry out an analysis of a list of RFC connections between ABAP-based systems and verify those of them that require the use of SSL and SNC. For protection purposes it's better to prevent connections with ABAP-based systems. Using SM59 transaction to manage RFC and its SNC settings, you can define the following SNC data:

  • SNC mode for connection (active or inactive);
  • quality of protection (QoP);
  • SNC partner name.

Other essential SNC settings (SNC AS name, external library location, maximum and default QoP), as mentioned above, are defined in the application server instance profile (these are profile parameters at the AS ABAP). To enable SNC for RFC adapter and the SAP system, it is necessary to install the certificate to the server. After that, on the RFC control screen (SM59 transaction), select the Change option and go to theSecurity & Logon tab. There, on this tab go to Edit --> SNC Options. In the appeared dialog window SNC extension: Details make the following changes:

  • Enter the quality of protection in the QOP field.
  • Enter the SNC communication partner name in the Partners field (if the start of external server program is defined at the application server or at the front end workstation, the SNC partner name will be received automatically from the existing safe route, with no need to specify it).
  • Save the SNC settings.
  • Return to the initial screen and enable SNC.


For the cases, where SSL is needed, it is recommended to perform the following actions:

  • execute the SM59 transaction;
  • select connection for which SSL is required;
  • in the Logon/Security tab, set the SSL option to Activate;
  • save changes.

SAP has launched their Version 1.0 of their new Security Product “SAP Enterprise Threat Detection” (ETD) earlier this year.

It is a brand new product based on SAP HANA that adds a complete different twist to the whole security discussion.

I was lucky enough to become invited to be part of the first Partner Ramp Up Workshop in Walldorf in May 2015 to get exclusive Hands-On Training and deep insights into the new product.


There are already a couple of good blogs by SAP about ETD, so I will not make another intro here. Just a quick rundown.

It is a new security concept based on the gathering and processing of security relevant events and log files. They are collected and fed into the “Event Stream Processor” that was part of the Sybase portfolio. This Event Stream Handler takes all the streams, extract the information and inserts them as normalized column-based objects into a SAP HANA instance. I never heard of the Event Stream Processor before and was surprised to see it as a blazing.-fast processor that sits on a small footprint Linux-server in front of HANA.



(picture copyright SAP SE (c) )


The processed data can be queried by SAP HANA via Fiori interfaces. The participants, all of them seasoned SAP consultants, where surprised by the slim and fast, but very informative and effective UI. “This is the very first 1.0 release ever by SAP that has a decent UI and is absolutely usable" said one partner.

This was also the first time I have seen HANA in action outside of demos and classrooms. There was seldom a technology that is even cooler on action than on paper. If you think that log file based security is boring and slow, think different.



(picture copyright SAP SE (c) )


Once the data are in HANA, there is a set of queries that will give insights into Security events and their exceptions. You can choose out of 100 so called patterns (and they are constantly growing) that is provided by SAP and that you can use to create a cockpit that will fit your security needs.

The patterns and their events can be customized and they are your approach to your own pattern-based security. Just to pick an example that I think is very handsome is the ability to read the RAL (Read Access Logs, protocols of data access) and create patterns around usage of SAP data. This is especially useful for tracking RFC-based security patterns.


Use Case "Catch the Debugger Enemy"


One impressive hands-on example was the setup, where you were debugging in a production system on the one side with “overwrite” activities during debugging. And some moments later, on the HANA side, you can see ETD raise an alert, because the debug based overwriting was detected, with terminal, user, variable and value. A typical case of “caught in the act”. You could actually hear security rush to that desk..


Log Learner


Another great feature was the “log learner”, that is part of the Event Stream Processor. You can dump any kind of log file, from simple to complex, and have “ETD” learn this format. ETD will detect time field, IP-fields, variables, constants and more and give you a “learned picture” from this log file, including all import routines and schedulers to insert it constantly in HANA as normalized column based pattern. This sounds not very challenging, but the degree of intelligence that is already in this 1.0 version is incredible. This usual manual nightmare of counting character, fields, delimiter and make them fit and import to databases is fully automated. You can add a lot of resource logs other than default SAP to this system with no significant effort.


Check the price tag


Those of you who think their companies will never afford ETD because of the usage of HANA, there is good news. The license of HANA is included in the license of ETD. Just add hardware. And – ask your local dealer – it is cheaper than you think. What I will say (before all SAP Salesman are at my desk), let’s have your SAP contact made a presentation for your company and you get an idea of where this is all heading to.

Installation is a matter of some days, give or take the complexity. But definitely not month. Activating the functionality is the same. Even the powerful out of the box function is a great security jumpstart.


My Two Cents Disclaimer

This is by no means a complete review. To keep this readable, I have written about the highlights that I think makes this software tool different than any other existing security tool. To check the complete feature list, look for the official SAP blogs and documents. But as you can tell, I am excited about this product and the new possibilties that comes with the usage of HANA.




The overall impression was that this is a great complimentary tool to your overall IT security strategy. And it is probably your entry ticket to the HANA world. SAP was stressing the point that this is not meant to be another SIEM tool. It is by far different. It will “Protect  Your SAP Crown jewels” (original quote)  and this is what it is doing perfect. It is not your network monitor, not your SIEM radar or your overall security monitor. It is your HANA based SAP Guardian and this is done well, profound and leading towards future security developments.

Most of the partner where fine with what is in this 1.0 version. A lot is missing, but SAP has acknowledged this lack and is eager together with partner and customers to continuously fill the gap. There is a defined roadmap to 2.0 and further on and there is still enough room for customer input.

I can only give the advice, in any serious security project, to look at the product (hands on), to check the price tag and open-minded consider the usage.

Martin Voros

Not So Simple

Posted by Martin Voros Jun 11, 2015

Not So Simple


Anyone who is somehow connected to SAP world must have noticed the new message pushed by SAP to their customers: “Simple”. Even their latest flagship product S/4 HANA has it in its name. I can’t imagine anybody who would object to this message. Nobody likes complexity. The question is that if we can really do something about this. Hasso and others from SAP argue that this complexity can be reduced with new technology that we have access to these days. Based on my experience almost every program gets more complex during its lifetime and there is often room for some improvement or refactoring.  This is also true for business processes. Hence there is definitely room for improvement and we just need to wait if SAP can deliver.


But what I would like to talk about is that the systems and enterprise landscapes are getting more complex. The systems used by users might be simpler to use with nice UI. But there is a hidden complexity that we, IT professional, need to tackle. E.g. Facebook looks like a simple app that provides value to its users but we know that there is a huge team behind that must manage this beast. So it might look simple to users but it’s not so simple to us, IT professionals.


Fiori Use Case


Let’s take a look at Fiori apps. The new Fiori apps are much nicer comparing to old GUI transactions. They represent how the users will access these new simplified apps. For some of them, you do not need HANA and almost every customer who is on sufficient release level can start using them right now. I am going to talk about the standard deployment scenario where you have a front end system that hosts the Fiori apps and is accessible from the internet. And there is a back end system such as ERP. You almost definitely want to go with this scenario. It allows you to be more agile with deploying fixes to the apps and based on my experience there are many fixes coming from SAP. It also has some nice security implications.


The following section is going to be more technical but I hope that it will help me to illustrate additional complexity introduce by Fiori apps. I am going to describe what happens when a user accesses a Fiori app. For simplicity, I am going to ignore Fiori Launchpad and I assume that the user accesses the app directly. I will also use the PO approval as an example.


  1. The user is accessing the app from external network from her mobile phone. The connection is required to be protected by TLS because the app can be accessed from external network.
  2. The user needs to be authenticated against front end system. Some of the standard methods provided by ABAP AS can be used. There might be a requirement to use two factor authentication to better protect access to the system.
  3. After successful authentication the user gets UI5 app. The app performs a call to front end system to retrieve a list of POs for approval.
  4. The front end system validates if the user has sufficient authorization to call OData service
  5. The front end system calls the back end system via trusted RFC to perform actual business logic.
  6. The back end system validates if the user has sufficient authorization to call OData service
  7. The back end system validates if the user has sufficient authorization to perform required business logic. The checks depend on application logic.


I highlighted in bold the steps that have impact on security. So what do we have here? We definitely need to protect HTTP connections using TLS. Sadly, this should be the norm even for internal systems but that’s not the case based on my experience.


We also need to be able to authenticate users in two different systems. Currently, most of the users will still need an access to back end system via SAP GUI. At this stage, the Fiori apps do not deliver all functionality. The scenario where the users have potentially two different passwords is not acceptable. There might be also additional requirement to provide two factor authentication for these apps.


Another thing is that it uses trusted RFC. What it means that we need to have a reliable way of provisioning user to multiple systems. Also different authorisation checks are being executed in different systems so we need to have two sets of different roles.


Side note: I understand that some big customers might have already solved these challenges/issues and adding additional front end system does not impose any challenge. Based on my experience with smaller SAP shops that very often use only ERP and BW this presents a real challenge.


This Fiori use case demonstrates how much new complexity is added to landscape comparing to having a simple ERP system. SAP is also pushing for hybrid cloud so you can image what the impact of introducing SaaS app in your landscape will be.


How Do We Tackle This?


So similarly to the ways of dealing with risk, you have the following options:

  • Avoid
  • Transfer
  • Reduce


Avoid – I am pretty sure that there is at least one SAP customer that decided that they will not implement the Fiori apps in their environment due to cost at this moment. The apps are for free (included in a standard license) but the cost of implementation is definitely not free. This is OK because it doesn’t create new risk but the customer is missing on benefits of the new apps.


Transfer – SaaS model offers the customers an option to transfer complexity to SaaS provider. The customer’s job is significantly reduced but there is still some stuff to do. You could argue that implementing SaaS might be taken as the third option Reduce.


Reduce – how are we able to deal with the complexity of new systems? It used be that a system administrator was responsible for handful of systems. How is it possible that these days one admin can administer 10 000s of servers? The answer is tools. We have much better admin tools that we can use to fight the beast of complexity. Do we have better tools in security space? There are definitely some tools that we can use to tackle complexity. In Fiori case it’s obvious that in this new environment with multiple systems we need to have a robust system for user provisioning a.k.a. identity management solution. The single sign on solution goes hand in hand with identity management. In this case using SAML would be good choice. So my suggestion would be to evaluate your current environment if it’s ready for the future and start implementing tools/systems that will help you to manage the complexity of the current systems.


TL,DR; there is a push to simplify user’s experience with business apps. This has impact on complexity of the systems that is hidden from users but visible to IT. So it’s simple to users, not so simple to us. The only viable way is to start building/implementing tools that will help us to tackle this complexity.


Please let me know your experience with tackling complexity in your landscape and how you are getting ready for the future.

SAP has released the monthly critical patch update for June 2015. This patch update closes a lot of vulnerabilities in SAP products. The most popular vulnerability is Missing Authorization Check. This month, three critical vulnerabilities found by ERPScan researchers Vahagn Vardanyan, Rustem Gazizov, and Diana Grigorieva were closed.

Issues that were patched with the help of ERPScan

Below are the details of SAP vulnerabilities that were found by ERPScan researchers.

  • An XML eXternal Entity vulnerability in SAP Mobile Platform on-premise (CVSS Base Score: 5.5). Update is available in SAP Security Note 2159601. An attacker can use XML eXternal Entities to send specially crafted unauthorized XML requests, which will be processed by the XML parser. The attacker will get unauthorized access to the OS file system.

  • A Hardcoded Credentials vulnerability in SAP Cross-System Tools (CVSS Base Score: 3.6). Update is available in SAP Security Note 2059659. An attacker can use hardcoded credentials for unauthorized access and perform various actions in the system. In addition, it is likely that the code will be implemented as a backdoor into the system.

  • A Hardcoded Credentials vulnerability in SAP Data Transfer Workbench (CVSS Base Score: 2.1). Update is available in SAP Security Note 2057982. An attacker can use the hardcoded credentials for unauthorized access and perform various actions in the system. In addition, it is likely that the code will be implemented as a backdoor into the system.


The most critical issues found by other researchers

Some of our readers and clients asked us to categorize the most critical SAP vulnerabilities to patch them first. Companies providing SAP Security Audit, SAP Security Assessment, or SAP Penetration Testing services can include these vulnerabilities in their checklists. The most critical vulnerabilities of this update can be patched by the following SAP Security Notes:

  • 2151237: SAP GUI for Windows has a Buffer Overflow vulnerability (CVSS Base Score: 9.3). An attacker can use Buffer Overflow for injecting specially crafted code into working memory, which will be executed by the vulnerable application under the privileges of that application. This can lead to the attacker taking complete control over the application, denial of service, command execution, and other attacks. In case of command execution, attacker can obtain critical technical and business-related information stored in the vulnerable SAP-system or escalate their own privileges. As for denial of service, the process of the vulnerable component may be terminated. For this time, nobody will be able to use this service, which negatively influences business processes, system downtime, and, consequently, business reputation. It is recommended to install this SAP Security Note to prevent risks.

  • 2129609: SAP EP JDBC Connector has an SQL Injection vulnerability (CVSS Base Score: 6.5). An attacker can use SQL Injections with the help of specially crafted SQL queries. They can read and modify sensitive information from a database, execute administrative operations in a database, destroy data or make it unavailable. In some cases, an attacker can access system data or execute OS commands. It is recommended to install this SAP Security Note to prevent risks.

  • 1997734: SAP RFC runtime has a Missing Authorization Xheck vulnerability (CVSS Base Score: 6.0). An attacker can use Missing Authorization Checks to access a service without any authorization procedures and use service functionality that has restricted access. This can lead to information disclosure, privilege escalation, and other attacks. It is recommended to install this SAP Security Note to prevent risks.

  • 2163306: SAP CommonCryptoLib and SAPCRYPTOLIB are vulnerable to FREAK (CVE-2015-0204, CVSS Base Score: 5.0). It allows an attacker to intercept HTTPS connections between vulnerable clients and servers and force them to use weakened encryption, which the attacker can break to steal or manipulate sensitive data. All the attacks on this page assume a network adversary (i.e. a man-in-the-middle) to tamper with TLS handshake messages. The typical scenario to mount such attacks is by tampering with the Domain Name System (DNS), for example via DNS rebinding or domain name seizure. This attack targets a class of deliberately weak export cipher suites. It is recommended to install this SAP Security Note to prevent risks.


References about the FREAK vulnerability:


It is highly recommended to patch all those SAP vulnerabilities to prevent business risks affecting your SAP systems.

SAP has traditionally thanked the security researchers from ERPScan for found vulnerabilities on their acknowledgment page.

In our previous articles we’ve already provided you the list of the 9 most important business application security critical issues [1],  covered patch management flaws [2], present the information about default passwords for access to the application [3], told about numerous unnecessary functions [4], open remote management interfaces [5] and security settings that do not fit into any of the critical issues groups [6].

Sixth critical issue. Access control and SOD conflicts. Few would try to argue that the SAP is immune to security system attacks and sensitive business data is well protected from the actions of adversaries. But now you have a chance to get to know about some of the basic operations one can perform to rise the SAP information security to a higher level. The goal of ERPScan team is to help IT personnel make critical decisions when identifying technologies and strategies to increase security in business. ERPScan team publishes a variety of original content, written by IT professionals as a way to increase infosec specialists' productivity around the world. Today, we're going to speak about the sixth critical issue (see the list of critical issues in our first article) and the steps related.

There are a lot of various functions in the SAP system implemented through programs, transactions and reports. It's essential that access to those objects must be restricted by means of setting up various authorization values that would define the types of users and objects allowed to have access as well as the ways to get access. In case users are allowed to perform critical actions, they can attack the SAP system, risen their privileges or steal critical data. Typical example, a user can have access to transaction that changes access rights or access to the transaction that allows a user to read any table.

Segregation of Duties (SoD) is a method of protection that prevents conflict of interests or, in other words, having two or more access rights. The matter is, if they are granted together this can lead to fraud actions. A classic illustration here would be having right to create Payment Order and at the same time having right to approve it. Thus, the SoD helps to segregate incompatible responsibilities.

In this article only 5 security check steps will be given, but those are the main access control checks having to do with the most critical access rights and the related settings. For the reason that Segregation of Rights is based on the business processes of each particular company and as usual it is developed individually, we will not describe relevant to the SoD security checks in the present article.

Further steps

There are at least 100 critical privileges solely in the SAP BASIS that we we'll talk about here, as well as the number of rights in each module is approximately the same. As has been already mentioned, sometimes these privileges overlap each other and it is the SoD matrix that is responsible for that. A standard matrix contains more than 200 different SoD patterns, while each company can additionally use their own ones.

As a further step you can choose to get critical access rights from the the ITAF regulatory document by the ISACA [7] or from the Deutschsprachige SAP Anwendergruppe DSAG standard [8]. Then, you should reconfigure the SoD. The best thing to do here, before starting the analysis of duties segregation, is to find out whether there are wildcards "*" in the access rights' authorizations values.

[EASAI-NA-20] The check for accounts with SAP_ALL profile Description


The SAP_ALL profile is a composite profile. It contains all the privileges for the SAP system including main administering functions and application settings. In accordance with the segregation of duties principle, this profile has no practical use.


A user that has the SAP_ALL profile privileges can perform any actions within the system. In case authentication data of the SAP_ALL profile user was compromised, an intruder can get an unrestricted access to any business data as well as to the critical business processes.


  • User privileges should be specified according to the least-privileges principle.
  • The SAP_ALL profile should be used in case of emergency only.
  • You should create only one user with such profile (for emergencies) and keep this user's password in secret. Instead of using the SAP_ALLprofile, it's better to distribute this profile's privileges between the appropriate positions. For example, instead of granting a system administrator all the SAP_ALL privileges, you should grant him only the authorizations relevant to system administering, in particular S_*. These authorizations will grant a system administrator enough privileges to administer the entire SAP solution, preventing him from performing tasks in other areas, such as, for instance, HR management.


[EASAI-NA-21] The check for accounts that may start any programs


If additional access control for particular programs was not implemented, a user authorized to run programs can start any program. That, in turn, happens very often, especially in client programs. To control access to programs, authorization groups are created. Each authorization group corresponds to several ABAP programs. Users can start only those programs that are included in the authorization groups assigned to their profiles.
So, users having the following critical access should be checked:

  • The SA38 transaction. It is used to execute programs and reports within the system;
  • The SE38 transaction. It is used to look through the programs' source code and to develop/debug them;
  • The SE37 transaction. It is used to start function modules;
  • The SE80 transaction. It is used to edit any objects being under development (i.e. in ABAP editor).



Those users who are allowed to run any program have an unrestricted access to all system functions and can severely damage the system, as far as there are more than 30K various programs that can perform almost any action, be it user account creation and OS command execution or paying for goods and modification of salaries.

If there is no control, any user having authorization object S_PROGRAM assigned to him and access to SA38 or SE38 can execute any program. Furthermore, with access to SE37 one can start any function module, to SE80 - perform editing of any objects being under development.

Editing and running of some programs can cause a risk that the program will send back inaccurate or incomplete information. Besides, if a user is allowed to start SE38 transaction, it can lead to unauthorized program modification that can impact system integrity.


  • Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
  • Its important, to add into the most critical programs additional authorization checks, by means of modification of their source code.
  • Besides, you should regularly review the policies, procedures and criteria used to specify authorized groups for the programs that are being created.


[EASAI-NA-22] The check for accounts with the privileges to modify sensitive tables with passwords


USR02, USH02 and USRPWDHISTORY are standard tables for the SAP-system, that contain sensitive user data. Those are, for example, usernames, password hash, user types, client ID, etc.
For access control over these tables, users with the following authorizations should be monitored:
For the SAP NetWeaver version with S_TABU_NAM authorization object support:


or (for all other versions):




Those users that have access to the listed tables have right to change password hash of any user. Thus, they can login the system under any account.


The number of users with access to USR02, USH02, USRPWDHISTORY tables must be restricted based on the business needs. The roles should be assigned according to the least-privileges principle.

[EASAI-NA-23] The check for accounts that may execute OS commands


For the SAP solution to interact with the host OS, there are specific mechanisms that manage interaction with external OS commands. Those OS commands can be executed by means of transactions defined in the SAP system. Moreover, only the users that have particular privileges can execute them.

The SM49 transaction allows to execute any external command (related to the OS). The SAP solution contains a detailed information for each external command, including the OS commands themselves, preset parameters and the information about whether additional parameters are permitted.

Users executing external commands should have authorization object S_LOG_COM assigned to them. The S_LOGCOM_ALL authorization object (based on S_LOG_COM) allows execution of all commands included in the S_A.SYSTEM and S_A.ADMIN standard authorization profile sets.

To control external commands, the SM69 transaction is used. It allows to modify them and to install additional security controls. The user should be granted with the S_RZL_ADM authorization object with the Activity value set to 01 in authorization profile.


The users that may execute or modify OS commands potentially can start critical OS commands and may damage the system.

Not being controlled, any user with access to SM49 or SM69 transactions (and access to S_LOG_COM or S_RZL_ADM authorization objects) can execute external OS commands of a SAP solution. There is also a risk that some commands after being edited or run will send back inaccurate or incomplete information. Besides, if user was allowed to start the SM69 transaction, this can lead to unauthorized command modification, which in turn can have a negative effect both on the OS and SAP solution integrity.


  • Minimize the number of users with these privileges, roles should be assigned according to the least- privileges principle.
  • Block these transactions and unlock them if necessary during utilization.
  • Besides, perform regular review of policies, procedures and criteria associated with authorization group set up for new programs.


[EASAI-NA-24] Check for disabled authorizations


Authorization checks are used each time when it is necessary to verify whether the user has appropriate rights to perform certain actions.

Checks of particular authorization values can be disabled at the system level. The check is not carried out if a system administrator has disabled authorization object check intentionally for the particular transaction (using SU24 and SU25 transactions). This could be useful, as while a transaction is being executed many authorization objects are being checked in a background mode as well.

To make those checks successful a user should have corresponding authorizations. As a matter of fact, some users have more authorizations than necessary. These authorizations along with some others may grant a user additional (extra) privileges and increase the workload. On the other hand, disabling authorization checks is risky as this means that system access defense mechanisms will also be disabled.To enable authorizations implemented by means of SU24/SU25 transactions, set the AUTH/NO_CHECK_IN_SOME_CASES profile parameter to Y (with RZ10 transaction). This setting is used by default in newer version of BASIS. This parameter allows to disable authorization check for individual transactions.


The absence of critical authorizations check can result in unauthorized critical actions performing to the system. Resulting from this, system efficiency will lower and fraud actions will become possible. Besides, such disabled authorization checks may indicate a backdoor in the system.


It is recommended to verify necessity of disabling authorization check for system authorization object in a particular program, transaction or RFC-function. Analyse program names, transactions or RFC-functions with system authorization objects where authorization check is disabled. Technically, disabled authorizations are marked in the USOBX_C table (a validation table for the USOBT_C table) with OKFLAG = N field value.

Authorization checks for corresponding authorization objects should be disabled only for the particular transactions and for the period of their execution.

With this article we are starting new series of posts giving a review of one of the most frequent vulnerability which affects a lot of SAP modules: cross-site scripting, or XSS. XSS is by far one of the most popular vulnerability indeed in all products and a most popular vulnerability in SAP products with total number of 628 vulnerabilities that is almost 22% of all vulnerabilities ever found in SAP during 12 years. You can find this in our latest research “Analysis of 3000 vulnerabilities in SAP” [1]. Only ERPScan researchers have reported about 52 XSS vulnerabilities in SAP products (by mid-2014).


Figure 1 - Ten of the most common vulnerabilities in SAP




XSS is dangerous because it allows an attacker to execute arbitrary JavaScript code in the context of the attacked user’s session. The code can yield access to cookie files, session tokens, and other critical data stored by the browser and used to work with the website. The attacker can get access to the user’s session and obtain business-critical information, or even get absolute control over the system. XSS can also be used to illegally change the data displayed on a website (phishing).


XSS usually appears if:


  • Server does not handle special characters typed by the user - '"& <>;
  • Server allows you to send dangerous values as a parameter, which allows to execute JavaScript code from other sources.


XSS is traditionally divided into several categories, described below.

Stored XSS


For this type of attack, malicious code has to be stored on a remote server. For example, attacker injects this code by reforming the name of an object which he is creating on the server. For instance, it can be a file name in SRM system. When after attack a legitimate user requests some information such as a list of files his browser will execute malicious code uploaded by an attacker.


Extremely powerful and business-critical attack with using this vulnerability was presented by us in SAP SRM long time ago, during one of SAP Security Assessments, and was described in SAP Security Note 1284360 [2]. In this organization, SRM system was used for bidding, and every supplier was able to post their bidding documentation with information about service and its price. The system was vulnerable to Stored XSS, so it was possible to inject malicious JavaScript code into file name field.  When Company’s employee from purchasing department  opens a folder with a list of file names to see newly uploaded documents,  injected code  automatically executes and the attacker gets access to Company’s employee account. By using this account, he manages to get access to Competitors bidding documentation and to find documentation about competitor’s service and price. This gives him a possibility to win Bidding by adjusting his price.

Reflected XSS


In this case malicious code is not stored on a server but executed by the victim user at the moment he opens malicious link such as:


In this case, to exploit vulnerability we need to somehow send a link to exploit to the victim. This type of XSS is less powerful because it needs user interaction, but much more popular than Stored XSS.


As an example of critical attack, you can embed into JavaScript code, not just a stealing user session located in Cookie, but it is also possible to execute an ActiveX component installed on victim’s workstation. Thus, it will be possible to get full access to his workstation by one of the ActiveX vulnerabilities. And, as a result, you get access to the corporate internal network and are one step closer to SAP Server itself with all corporate data.


In this type of XSS, the attacker changes the DOM (Document Object Model) environment of the victim’s browser page so that some of the scripts on this page execute malicious JavaScript code. Let’s look deeper into this vulnerability looking at SAP Security Note 1788080 [3] for example.


The vulnerability exists because user input in the JSP script ‘error_msg.jsp’ is not filtered, so an attacker can inject malicious JavaScript code into a page.

Figure 2 - Example of page vulnerable to cross-site scripting


The listing shows that the attacker can use the variable ‘id’ to inject code (string 15) because ‘id’ value will be displayed on the user’s screen without any filtering (string 28).


So the exploit for this vulnerability is the following query:
http://example.com/dir/start/error_msg.jsp?id=1111">   <script>alert(123)</script>

General defense


To avoid such vulnerabilities, you must always remember to screen/filter any user input. In our example of DOM XSS, the variable ‘id’ has to be re-laid to the method ‘URLEncoder.encode()’ firstly because its value is used as an HTTP request parameter.


Figure 3 - Necessary action to close the vulnerability

To sum up, there are some tips on preventing XSS vulnerabilities during development:


  • never insert data from untrusted sources (including any user input) into an HTML page;
  • screen HTML from untrusted sources before inserting it into HTML Element Content;
  • screen HTML tag attributes from untrusted sources before inserting them into HTML Element Content;
  • screen JavaScript code from untrusted sources before inserting it into JavaScript Data Values;
  • screen JSON from untrusted sources before inserting it into HTML Element Content or using it in JSON.parse;
  • screen CSS from untrusted sources before inserting it into HTML Style Property Values;
  • screen URLs from untrusted sources before inserting them into HTML URL Parameter Values;
  • protect your systems from DOM XSS.


There are also some notable mechanisms in browsers which allow decreasing the risks of discovered XSS attacks:


  • use the flag ‘HTTPOnly’ for cookies - this security measure will prohibit getting user session values form cookie files by JavaScript;
  • implement Content Security Policy - this security measure will restrict using JavaScript within the domain;
  • HTTPS Cookies protection -  Secure cookie while using HTTPS.


Stay in touch with us, as next week we’ll come back with the new article describing how to secure different SAP Applications from XSS.

In our previous articles we’ve already presented you the list of the 9 most important business application security critical issues [1],  covered patch management flaws [2], provided the information about default passwords for access to the application [3], told about numerous unnecessary functions [4] and open remote management interfaces [5].

Each application has several security settings that do not fit into any of the critical issues groups mentioned in our series of articles. Among such settings there are both standard settings (such as password length or the number of attempts given to enter invalid password) and the specific to the system, individual settings. In this article we are going to use as an example the SAP Gateway service access settings.

[EASAI-NA-15] Minimal password length


While choosing a new user password, consider that passwords should meet the SAP system requirements and correspond to the corporate policy. Various profile parameters are set up in order to control that passwords meet the requirements. Out of all those parameters,login/min_password_lng is the main one. It specifies the allowed minimal password length. This parameter’s default value is 6, although it's acceptable to use values ranging from 3 to 40.


In case the minimum password length is set to less than 8 symbols, an adversary can easily decrypt a password using USR02 table hash. Alternatively, one can gain access remotely by bruteforcing the password, if the login/fails_to_user_lock parameter is set incorrectly. The login/failstouserlock parameter defines the number of available invalid login attempts, before the user’s account is locked out by the system.


Set the login/min_password_lng parameter value for more than 8, otherwise choose the value which is in accordance with the company’s security polity. This way, you can lessen the risk of potential attack.

[EASAI-NA-16] Number of invalid logon attempts before the user account lock out


The login/fails_to_user_lock parameter defines the maximum number of incorrect passwords allowed to be entered before the user account is locked out. It’s very important as it interacts directly with the login/min_password_lng parameter. The login/min_password_lng parameter, in turn, defines the minimum password length, and thus, prevents remote password bruteforcing. This parameter’s default value is 5, although it’s acceptable to set values ranging from 1 to 99.


If the login/fails_to_user_lock parameter is set incorrectly or has a low value, an adversary may succeed in carrying out a brute force attack and get an unauthorized access to user credentials.


Set the login/fails_to_user_lock parameter value for not more than 6. This way, you’ll lessen the risk of potential brute force attack.

[EASAI-NA-17] Password compliance with the security policies in place


The login/password_compliance_to_current_policy parameter is highly important. If this parameter is absent or is set to 0, the password length and complexity settings would affect only newly created users. Thus, the settings would not be automatically applied to all the other users. Consequently, all of those old users would have insecure passwords.
If this parameter is set to 1, the settings would affect old users with insecure passwords and force them to choose secure ones upon their logging into the system.


If the login/password_compliance_to_current_policy parameter is set to 0, password policy compliance for old users is not set. This allows users to have insecure passwords. As a result, these user accounts are easy to be compromised.


Set the login/compliance_to_current_policy parameter to 1 to apply the password policy requirements for all users, including those newly created.

[EASAI-NA-18] Access control settings for RFC-service (reginfo.dat)


The SAP Gateway is the application server technical component with RFC-based functionality that manages communications between various SAP systems. Since the gateway is an interface of application server for external connections (with other SAP systems, external programs, etc.), higher security requirements are applied to it.The SAP Gateway security is managed by the reginfo and the sec_info files. The reginfo file is defined by the gw/reg_info parameter and the sec_info file is defined by the gw/sec_info parameter.

Some clients may be allowed to register their services on the server. Specify the services registered in the reginfo file to control the access to them, cancel their registration, determine external server services allowed to be registered on the gateway. The file name (file path) is defined by the gw/reginfo parameter. The default file path is: /usr/sap/<SID>/<INSTANCE>/data/reginfo.
If this file doesn’t exist, any server processes may be registered from any hosts. Speaking of which, starting from the kernel version 7.20 and higher, for security purposes, this process is restricted by the gw/acl_mode instance profile parameter. For further references, see SAP Security Note 1480644 [6]. However, if this file exists but it is empty or has no valid records, it is not allowed to register.

If somebody tries to register a service on the gateway, valid record is searched for in the file. The record specifies this user’s right to register this particular service. If the record is not found, user’s registration is denied. It is crucial to understand that the reginfo file can be read only ONCE, when a program is being registered. All the further changes and restrictions in the reginfo file do not affect successfully registered programs.


In case the reginfo.dat file is absent or its configuration is incorrect, an adversary may register any service on the SAP Gateway and get an unauthorized access to the SAP server. As an example, a wildcard “*” can be used in host definitions, signifying that service’s registration is available from any host. One may register a new service that would perform malicious functions. It may be registered under the same name, as has the service that already exists. Thus, a legitimate user would be able to run it.


Unauthorized service registration may be avoided by means of creating a reginfo.dat file in the SAP Gateway data directory. If the file exists, the system checks the availability of rights to call remote RFC functions from this file. This way, it prevents unauthorized access.

File records should have the following syntax (note that each line must have TP record, all the other parameters are optional):

TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>], where:


TP=name is a registration ID of the external server program.
NO=n shows what number of registrations with that ID is allowed.
HOST=<host> is (a) name(s) of a host using which registered servers are allowed to enter the system. Here you may specify host names’ list, IP addresses, domain names or subnet masks. The registration is allowed only if the server enters the system from this node. Without this optional parameter, it is allowed to register from any host.
ACCESS=<host> is(are) host name(s) that has (have) the right to use the registered service. Here you may specify the list of host names, IP addresses, domain names or subnet masks. The local system is always allowed to use the server. Without this optional parameter, the server is accessible from any node.
CANCEL=<host> is(are) (a) host name(s) that allow(s) to log off the registered system server. The same rules are applied as has the ACCESS parameter.

Starting from the version kernels 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher, permit and deny values are added to the syntax. They are indicated by the Latin upper-case letters P and D respectively (see SAP Security Note 1105897 [7]). P means that a program is allowed to be registered, (as in the old syntax line); D prevents registration. The first line layout in such file is #VERSION=2. All the next lines are structured the following way: P|D TP=name [NO=<n>] [HOST=<host>] [ACCESS=<host>] [CANCEL=<host>]

Warning! The system reads key words only if they are written in upper-case letters. Incorrect specification leads to HOST=* wildcard value, which would probably be undesired (there are instructions on how to fix it in SAP Security Note 1473017[8]).

In all the host names’ lists (HOST, ACCESS and CANCEL), key words must be separated by commas. Any space would indicate the end of host names’ list.

You can find detailed syntax review in SAP Security Note 1069911 [9].

For the correct reginfo.dat configuration use recommendations from SAP Security Note 1425765 and 1408081. [10][41], [11].

[EASAI-NA-19] Access control settings for RFC-service (secinfo.dat)


In the secinfo file, you may specify which external services may be started. Also, you can specify who can register external server services on the gateway. And lastly, which external services can be registered on the gateway. Note that this concerns only kernel versions 46D and lower. Starting from the version 6.40, service registration from external servers is controlled with a separate RegInfo file. In other words, secinfo security file is used to prevent unsanctioned start of an external program. File name is defined by the parameter gw/sec_info. Default file path is:/usr/sap/<SID>/<INSTANCE>/data/secinfo.

If the file does not exist the system runs all external programs. In case, this file is empty or has no valid lines, no external service may be started.

Upon the start of an external service, the system scans the file, searching for a valid record. If it was not found, the system shows error message, and cancels the service start.


In case secinfo.dat file is absent or misconfigured (e.g., it has “*” wildcard in host, program of subnets definitions), an adversary may run a service registered in the SAP Gateway, and get an unauthorized access to its functionality. In some cases, if the program can execute OS commands, one may access the SAP server.


You should create secinfo.dat file in the SAP Gateway data directory. This way it would be possible to prevent unauthorized program launching. If the file exists, the system checks the availability of rights to call remote RFC functions from this file. This way, it prevents unauthorized access.

File records should have the following syntax ( USER, HOST and TP lines are obligatory, and other parameters in each line are optional):
TP=name HOST=<host> USER=<user> [USER-HOST=<user-host>], where:
TP=<program name> is the name of a program, you would like to run (in addition, you can specify a wildcard for program ID, e.g., TP=XYZ*)
HOST=<host> - name of the host where you would like to run a program. It defines destination address. Note the following difference: in thereg_info file syntax, this parameter specifies client address; it is available starting from the version 6.40, patch 194; 7.00, patch 119 and higher versions.
USER=<user> is the name of the user who would like to start a program. In case the program starts from application server, this is username for the system. However, if the program is external, this is OS username.
USER-HOST=<host> (or a source address) is a hostname of the user who would like to start a program. For security purposes, it is strongly recommended to install this option (SAP Security Note 1434117 [12]).

In 6.40 and lower versions, PWD=<Password> parameter was supported (ignored in newer systems).

In 6.40, patch 212; 7.00, patch 139; 7.10, patch 80, and higher kernel versions, there appeared additional permit and deny values indicated by the Latin upper-case P and D respectively (see SAP Security Note 1105897 [13]). P permits to run the program (the same as the old syntax line); Ddenies it. The syntax of the first line in such file is #VERSION=2, and that of all posterior lines is:

P|D TP=<tp> HOST=<host> USER=<user> [USER-HOST=<userhost>]

Warning: the system reads key words in the upper-case only. Incorrect specification leads to the HOST=* wildcard value, which is undesired. (there are guidelines on how to fix it in the SAP Security Note 1473017[14]).

For detailed explanation of this syntax check out the SAP Security Note 614971 [15][44].

For the correct secinfo.dat configuration refer to SAP Security Notes 1408081, 1525125, 1425765. [16][17][18]

Further steps.

The number of various security settings to be fine-tuned is enormous, and there are specific ones to each particular SAP solution or module. As the starting point, you can refer to the document called SAP NetWeaver Security Guide. There you can find the User Authentication section. Afterwards, you better switch to a more detailed description of the papers where each module and service security configuration is described.

Today we are going on with our series of articles where we describe the 33 steps to security. In our previous articles we’ve already presented you the list of the 9 most important business application security critical issues [1],  covered patch management flaws [2], provided the information about default passwords for access to the application [3] and told about numerous unnecessary functions [4].

The subject is of great significance not only to a small group of SAP infosec specialists, but to all those people who work with ERP systems as recent years have witnessed an increased awareness of business data protection problems. Not to go into details, let us get right to the topic.

The SAP NetWeaver platform includes not only the Dispatcher service responsible for SAP GUI user connections, but it also includes a whole range of other services. Each of them listens to a remote port and accepts network connections. Some of these services grant administrative access and remote administration functions. Some of them also grant access to various technical services. Load balancing system of the SAP Message Server and remote administration system of the SAP Management console are among them.


One can connect to these services via the corporate intranet or the Internet. What is more, in case those services’ settings are insecure, they are manageable remotely without authentication data.


So, this section contains information about the most insecure services. Their settings should by no means be accessible via the corporate intranet.

Further steps

Except those services we are going to discuss, the system has other less critical and widespread services (e.g. the Message Server HTTP). But you should restrict access to them as well. For a full list of SAP services, check out “TCP/IP Ports Used by SAP Applications" paper [5]. The list’s content depends on the installed components of each particular system.

Besides, it is also advisable to check third-party services that may be enabled on this server, such as remote administration interfaces for various DBMS, remote monitoring and data backup systems, etc. The thing is that you should restrict access to them using authentication both at the network and application levels, if possible.

[EASAI-NA-11] Unauthorized access to the SAPControl (SAP MMC) service functions


The SAP Start Service starts on each computer simultaneously with the SAP solution instance. In Windows, this process is executed with sapstartsrv.exe, in UNIX - with sapstartsrv. The SAP Start Service provides the following functions for the SAP solution, instance and process monitoring:

  • start and stop;
  • monitoring the active state;
  • reading logs, trace files and configuration files;
  • technical information, for example, on network ports, active sessions, etc.

These services are accessible via the SAPControl SOAP Web Service and are used by the SAP monitoring tools (SAP Management Console, NetWeaver Administrator and others). When service starts, it uses the following ports:

  • HTTP port 5<xx>13 (or sapctrl<txx> in /etc/services), where <xx> is the instance number;
  • HTTPS port 5<xx>14 (or sapctrls<xx> in /etc/services), where <xx> is the instance number.

For example, when service starts, either the HTTP port 50013 or the HTTPS port 50014 is used for the instance 00. [6]. This process allows to read various system data without user's consent. However, it requires user authentication for secure operations, such as to start or stop the SAP instance. Startsrv controls internal list of secured operations (depending on the version of the release, default list may differ). If necessary, you can change the list using service/protectedwebmethods parameter.


By means of many insecure methods, one can get access to system configuration data, request system status, read the log and trace files that may contain user passwords or HTTP session files. Eventually, this data can be used to implement more critical attacks.


In accordance with SAP Security Note 1600846 [7], sapstartsrv settings must be reconfigured. To do this, you need to set the parameter service/protectedwebmethods to DEFAULT in a default system profile (DEFAULT.PFL). To apply the changes, restart all sapstartsrv services in the cluster. Besides, this change of value, also involves implementation of a list of all critical methods by default. Instead, you can use the value ALL (i.e. all methods), though it is considered excessive (the parameter and its values are described in detail in SAP Security Note 927637 [8]).

Implementation of SAP Security Note 1439348 [9] along with related recommendations may be seen as an additional method of patching this vulnerability.

It is advisable to restrict access to this service by IP-addreses. To do this, you need to define Access Control List (ACL) by changing values of services/http/acl_file and /https/acl_file.

[EASAI-NA-12] Unauthorized access to the SAPHostControl service functions

DescriptionThe SAP Host Agent is a component designated for other components management, their control and monitoring. It consists of the following services and programs:

  • The SAPHostExec is a control program that runs under root (UNIX) or LocalSystem (Windows) accounts. It controls all the functions called for by the specific users of this type, such as saposcol and sapacosprep OS collectors. The program is connected with the sapstartsrv in a host mode via the local socket that provides high-speed and secure connection (see the picture). It also starts simultaneously with the host.
  • DB4STATS and SAPILED are the programs that supply IBM I with the SAP Database Performance Collector and the SAP ILE daemon respectively.
  • The SAPHostControl (sapstartsrv in the host mode) is the SAP NetWeaver management agent. It is an executable of sapstartsrv run in the host mode under the sapadm user. It is using remote TCP 1128 port. That is why it is responsible not for the SAP instance, but for any host monitoring, which is controlled centrally.

A profile used while starting executable files also determines whether sapstartsrv will run in an instance operating mode (with an appropriate instance profile) or in a host mode (with the host's own profile that may include parameters SAPSystem = 99, SAPSystemName = SAP). [10]

For data transmission, the SOAP protocol is used. In case encryption is set up, it encapsulates into the SSL. This service allows to read some system information without user’s consent. It also has vulnerabilities that allow to run OS commands remotely.
ThreatAn authorized adversary can run any random code, caused by the SAPHostControl service maintenance error remotely using the SAP NetWeaver. This happens when this service does not properly validate incoming data of the SOAP management interface. With the SOAP interface running on TCP port 1128, an adversary can exploit this vulnerability to inject and execute random commands to the system having administrative privileges.

Many insecure methods make system configuration or status data requests possible. One can also read logs and trace files that may contain user passwords or HTTP session files. Also, remote execution of OS commands using OS command injection vulnerability becomes available (see SAP Security Note 1341333 [11]). This data can be used to implement more critical attacks.
SolutionRemote execution of random code vulnerability was fixed in May 2012 with SAP Security Note 1341333[12].

SAP Security Note 1816536 [13] released in April 2012 prevents information disclosure. Resulting from this, it’s sufficient to apply both of these security updates to fix vulnerabilities.

In order to additionally secure the service you can restrict access to it by IP, using a personal firewall or by means of network equipment, granting access only from those servers where you take data from.

[EASAI-NA-13] Unauthorized access to the Message Server service functions


The SAP Message Server is a system component that, on the one hand, manages communication between application servers (dialog instances) within one SAP system and, on the other hand, ensures balancing of a load coming from such clients as the SAP GUI.

In standard, lower than 7.0 versions, Message Server port is used for interaction of both clients and application servers. Starting from the version 7.0, Message Server port is by default divided into an internal and an external port. An internal port is used for application connections to the server, while an external port is used for end-user connections.

In order to control the list of addresses one can connect to the Message Server with, you need to activate the Access Control List (ACL). To do this, use ms/acl_info parameter. It indicates the file where you can configure access to the Message Server. This file contains application server's host and domain names, IP addresses and/or subnet masks using which you can access the Message Server. External clients that retrieve data from the Message Server are not anyhow affected by this. The data remains accessible. Default parameter value is /usr/sap/<SID>/SYS/global/ms_acl_info.


In case ACL file is absent or misconfigured, malicious software or potential adversaries can access the Message Server, register their own application server and perform "man-in-the- middle" attacks. In other words, intercept credentials of legitimate users trying to connect to the Message Server. This can result in gaining unrestricted access to user accounts.


It is essential to configure ms/acl_info parameter. It indicates the ACL file that has an authorized access to the Message Server.
(default value: /usr/sap/<SID>/SYS/global/ms_acl_info). This file should contain application servers' host and domain names, IP addresses and/or subnet masks from which application servers are allowed to address the Message Server. They address the Message Server using the following syntax:
HOST = [*| ip | hostname | network mask | domain ] [, ...]

Configuration file accepts the "*" wildcard in access control description (e.g., HOST = *.sap.com or HOST = 157.23.45.*). The "*" wildcard should be avoided, especially when in the HOST = * form, as it makes access from any workstation possible.

Access control settings do not affect the retrieval of technical information from the Message Server. It remains always accessible.
As an alternative to ACL file configuration we suggest the following options:

  • In 4.5 and lower releases, Message Server port defined by rdisp/mshost and rdisp/msserv parameters should be blocked by the firewall. Only those network segments with SAP servers should be granted access to this port.
  • For 6.4 and lower releases, it is highly recommended to distribute Message Server services between the two ports - one for the SAP GUI client access (rdisp/msserv), the other one - to access internal connections with the server (rdisp/msserv_internal).


[EASAI-NA-14] Unauthorized access to the Oracle DBMS


Currently, Oracle Data Management System (DBMS) is the most widely spread DBMS along with the SAP. Unfortunately, if installed together with the SAP, this DBMS has insecure REMOTE_OS_AUTHENT settings. REMOTE_OS_AUTHENT ensures execution of trusted operations between various SAP solutions.

More importantly, it is able to circumvent such security checks, in particular DBMS password check. The only way to mitigate this risk is to restrict remote access to Oracle DBMS port by preserving it only for necessary servers by IP addresses.

This setting is implemented by means of the Sqlnet.ora configuration file. In particular, it has to do with tcp.validnode_checking parameter, which is required to validate host names while they attempt to establish inbound connections. When this parameter is set to yes value, inbound connections are only allowed if they come from the note listed in TCP.INVITED_NODES or TCP.EXCLUDED_NODE. Note that, the first one is of higher priority.

TCP.INVITED_NODES, in turn, requires each client host to be included in the sqlnet.invited_nodes server list.


If restrictions for client nodes are not set, an attacker can connect to the Oracle DBMS without password, using a trusted login $OPS<SID>adm. Thus, the attacker will get almost unlimited access to the DBMS.
Next step is to decrypt SAPR3 user password. One can take it from the SAPUSER table and connect to the DBMS with this user’s privileges. This user has a full access to the SAP data, thus an adversary can get an unlimited control over the system.


Set the tcp.validnode_checking parameter in the sqlnet.ora file to “
yes. This way it’s possible to check whether there are inbound connections coming from the permitted nodes listed in sqlnet.invited_nodes.

It’s imperative to specify all the necessary client hosts in the sqlnet.invitednodes server. It is recommended to leave only the trusted systems in this list.


Filter Blog

By author:
By date:
By tag: