1 2 3 11 Previous Next


161 Posts

There are a lot of things to like about the latest version of SAP Enterprise Threat Detection. In this blog I am going to introduce one of the more subtle improvements – semantic events.


Semantic Events

Take a look at the screenshot and compare the two filter paths. Can you guess what each does?


If you are intimate with the Security Audit Log in AS ABAP, you will of course know that the Event ID AU2 indicates that a user has attempted a dialog logon and failed. If that log type is not so familiar to you, I suspect you would rather deal with the semantic event "User, logon, failure, dialog".


Usability is not the only difference though. In the screenshot, both paths found the same event because the failed logon took place in an ABAP system. By using the semantic event, Path2 is not restricted to events from ABAP systems. Therefore, many of the attack detection patterns delivered in SP02 are now based on semantic events to broaden their applicability.


Relevant SAP Notes

2139392 - Release Note SAP Enterprise Threat Detection 1.0 SP02

When you see the error in system log, it means report RSUSR003 ran at that time and security violation was detected.


First step is to ensure note 1451760 is applied in the system.


If the error persists though you have implemented note 1451760, it means there is real security risk.


Run report RSUSR003 and check "Password Status" column, if there is any record shown in red background, change the password for the user to something which is not well known and not guessed easily..


After all records with background color are elimated, "Security Check Passed" will appear in system log while running RSUSR003 and it means no security risk for the standard users.


In some systems, you may find that RSUSR003 runs automatically though it is not intended.


This is because during EWA data collection, the collection program will call RSUSR003 to collect passwod status for standard users.


Relevant notes/kbas:


1451760 SUIM|RSUSR003 - inappropriate security violation message


863362 Security checks in SAP EarlyWatch Alert, EarlyWatch and GoingLive sessions


1610103 EarlyWatch Alert Report : section Default Password of Standard Users

Today’s post is the last in the series of articles about XSS vulnerabilities in SAP systems. The previous parts describe how to prevent XSS in SAP NetWeaver ABAP and SAP NetWeaver J2EE.


XSS is one of the most popular vulnerabilities and its effect can range from a petty nuisance to a significant security risk, depending on the sensitivity of the data. In SAP products, 628 XSS vulnerabilities were discovered that is almost 22% of all vulnerabilities found in SAP in 12 years.

From the developer’s perspective

There are several rules of protecting SAP HANA using SAP UI5 framework.


  • Validation of typed control properties - SAPUI5 core validates the value of properties set by the application against the type of the property. This guarantees that an int is always an int, and a sap.ui.core/CSSSize is a string representing a CSS size and does not contain a script tag. This also applies to enumerations and control IDs. The control renderer can rely on this check when writing the HTML.
  • Escaping - use helper methods to escape the value of a string property that is written to the HTML:
    • Use writeEscaped(oControl.getSomeStringProperty()) instead of just write(...) for writing plainly to the HTML.
    • Use writeAttributeEscaped(“someHtmlProperty”, oControl.getSomeStringProperty()) instead of just writeAttribute(...) for writing attributes.
    • Use jQuery.sap.escapeHTML(oControl.getSomeStringProperty()) for string properties where none of the other two options is possible to escape the string and then process it further.

From the administrator’s perspective


The administrator has to set the following parameters to improve security:

  • sessiontimeout = 900. Enable session timeout to minimize potential attack window.
  • HttpOnly cookie is enabled by Default.

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.


  • To monitor all HTTP(s) requests processed in a SAP HANA system, you can set up the internal Web Dispatcher to write a standardized HTTP log for each request. To configure the Web Dispatcher to log all HTTP(s) requests, you add the property icm/http/logging _ 0:
    • set LOGFILE value to path_to_file Securing SAP Systems from XSS Vulnerabilities
    • 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.
  • global _ auditing _ state = true. The following configuration parameter for auditing is stored in global.ini, in the section auditing configuration. This can help you to log additional information such as logon’s logoffs and database requests which can be relevant for investigating XSS Attacks. You can find this configuration in SAP HANA Administration Console –> Security HDB –> Auditing Status menu.

Sometime, in a special scenario, you might get some SSO issue, and find it is related to the user locking.

  That is when the user is locked, the SSO could not work as usual, user get a logon page.


The main point of troubleshotting such issue is, find out the complete scearion of this issue.

   Make clear who is the SSO enter, who is SSO credencial issuer, which SSO type between.


Here finially, the scenario is this:

1. The enter is the corporation Portal for all business.

2. There has a link point to a iView of another Portal (second Portal).

    And these 2 portals are Federat Portals. So the SSO type between them is Logon Ticket.

3. The second Portal use a ABAP (BW) system as its UME data source.


The whole issue is, when user password gets locked in ABAP system (by many invalid password logon), the user will not SSO from enter portal to second portal.

Even if, the ABAP parameter login/failed_user_auto_unlock=1 has been set. The user still could not logon on next day.


Then from the logon page properties, find it belongs second Portal, So confirm the issue is on Portal/Java side, not the ABAP side.


Finially, found the reason is when user get locked (from ABAP side), the Portal/Java system will not let user logon via SSO.

And there has a UME property could control this: ume.logon.allow_password_locked_users_sso_login.


More information is in these Notes:

#1708850 - User is authenticated even though change password fails

#1900890 - Allow login of users whose password Is locked via SSO


After set this property, the user could logon via SSO when user password is locked.

(No matter the user is in Java own data source or other ABAP data source.)


(Others, the user lock status will not be changed when logon via SSO,

  only the correct password logon could change it automatically.)


Hope this blog could help you on troubleshooting of similar issue.



The standard restriction with Authorization Object: B_BUPA_ATT dont works correctly (the BP transaction dont refresh the authorization error), the best way is create the restriction aith an Z authorization Object and a Badi:       *******************************************************************************************************        

The BP restriction by header field "Grouping"



We will use a Badi doing a check of authorities with an Z authorization object.

The steps to follow are:


1. We go to SU20 and we define a field ZGROUPING (this field will be use in the Z authorization object), we need add the name field and the elemend data:



2. Next go to SU21 and we will create a Z Authorization Object ZGROUPING using the field that we defined before



3. We go to transaction SE19, and next we will add the corresponding code in the Badi of the BP. We need to go SE19 and we will create an implementation of the Badi: BUPA_FURTHER_CHECKS called ZBUPA_FURTHER_CHECKS



4. The next step will be update the implementation created: ZBUPA_FURTHER_CHECKS, inside of it, we will go to tab "Interface" and double click in the method CHECK_CENTRAL:



5. It will open a code line where we need add the corresponding Authity-Check (using the Z authorization object created), I  used the following ABAP code:


IF sy- subrc <> 0.
MESSAGE e000(zish_pa ) WITH text- 001 iv_group.




6. We go to PFCG transaction and we need to create a Z test role  adding the BP transaction by role menu (I usually add XK03 and XD03 transactions too), we need complete all authorizations and add the ZGROUPING authorization object created, resticting the values that we need to restrict.



In this case, the role will have access to the following Groupings: ZBAN, ZDR1, ZDR2 and ZDR3

En nuestro caso, al rol le vamos a dar acceso a los Groupings: ZBAN, ZDR1, ZDR2 y ZDR3

7. We need to create a Test user (into SU01 transaction) and we will asign the test role ZTEST (I usually add the standard role SAP_BC_ENDUSER to give access to basic transactions as SU53, etc.)


Note: Is possible that before assign the standard role SAP_BC_ENDUSER, we need generate the profile of this standard role.




8. We log-in with the test user and we go to BP transaction to force the authorization error. We need to create a Business Partner for the Grouping ZPAT (the test used dont has access to this Gropuing). Next we will create a Business Partner to Grouping ZDR1 (he has access to this Grouping), to check that the restriction works correctly.




I am displaying the SU53 transaction (with the authorization error):




Next, we will create a BP for ZDR1, the user should to have access:





Done, with this, we have created the required Grouping restriction into BP transaction.

Do you have cloud applications for your employees or partners that you want to protect in a more secure and reliable way?


With SAP Cloud Identity, you can now decide which applications you want to protect better.

If you configure an application to have two-factor authentication, once the user of this application provides valid username and password, additional one-time password will be required as a second authentication factor.


What is one-time password (aka OTP or passcode)?


It is a 6-digits passcode (for example: 899866) that expires in 30 seconds. For the generation of the passcodes, the users need to install SAP Authenticator on their mobile device. It is a free mobile app available on iOS and Android.


Let’s take a closer look at the steps you need to enable two-factor authentication for your application.


  1. In the Administration Console for SAP Cloud Identity service, you need to open the Authentication and Access Tab for the application you want to configure.
  2. You just need to switch the slider to ON and two-factor authentication is enabled for this application. It is as simple as that.


What are the steps for the end users?


The users of a sample application “Green Holidays” need to enter correct username and password. As a second step, they are asked to enter a passcode, and then the authentication to the application is successful.


First Step:


Second Step:


If the user has a device already registered to generate passcodes for the two-factor authentication, she or he just has to enter the passcode from the mobile device, and will log on to the application.


If the user submits 5 incorrect passcodes, the passcode is locked for 60 minutes. A tenant administrator has an option to unlock manually the user passcode in the Administration Console.


If the users decide to use the feature “Remember me”, the passcode will still be required, only the first step when the users enter their credentials will be skipped.


How to activate a device that will generate passcodes?


The user needs to proceed as follows:

  1. Open the User Profile page in a web browser and press Activate under Two-Factor Authentication.
  2. Open SAP Authenticator app on a mobile device. Call the Add Account screen and scan the QR Code.
  3. Tap Add Account on your mobile device.
  4. Return to the User Profile page and enter the passcode generated by the SAP Authenticator and press Activate.


The two-factor authentication is now activated. The user is able to login with a second factor to all applications from this SAP Cloud Identity tenant that require an OTP.


For the generation of the passcodes, SAP Authenticator uses a Time-based One Time Password (TOTP) Algorithm defined as an open standard RFC 6238.

Alternatively, you can use another application for the generation of the passcodes that is based on the same algorithm (e.g.  the Google Authenticator app).


Ensuring a higher level of security for your applications is a matter of a few steps to enable two-factor authentication. It is really that easy and it is really worth it.


For more information on other SAP Cloud Identity service features, please find a link to the official documentation.

SAP has released the monthly critical patch update for July 2015. This patch update closes a lot of vulnerabilities in SAP products, some of them belong in the SAP HANA security area. The most popular vulnerability is Missing Authorization Check. This month, one critical vulnerability found by ERPScan researcher Alexander Polyakov was closed.

Issues that were patched with the help of ERPScan


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


  • A Missing Authorization Check vulnerability in SAP XML Data Archiving Service (CVSS Base Score: 3.5). Update is available in SAP Security Note 1945215. 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 an information disclosure, privilege escalation, and other attacks.

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:

  • 2180049: SAP ASE XPServer has a Missing Authorization Check vulnerability (CVSS Base Score: 9.3). 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.


  • 1952092: IDES ECC has a Remote Command Execution vulnerability (CVSS Base Score: 6.0). An attacker can use Remote Command Execution to run commands remotely without authorization. Executed commands will run with the privileges of the service that executes them. An attacker can access arbitrary files and directories located in an SAP server filesystem, including application source code, configuration, and critical system files. It allows obtaining critical technical and business-related information stored in the vulnerable SAP system. It is recommended to install this SAP Security Note to prevent risks.


  • 1971516: SAP SERVICE DATA DOWNLOAD has a Remote command execution vulnerability (CVSS Base Score: 6.0). An attacker can use Remote Command Execution to run commands remotely without authorization. Executed commands will run with the privileges of the service that executes them. An attacker can access arbitrary files and directories located in an SAP server filesystem, including application source code, configuration, and critical system files. It allows obtaining critical technical and business-related information stored in the vulnerable SAP system. It is recommended to install this SAP Security Note to prevent risks.


  • 2183624: SAP HANA database has an Information Disclosure vulnerability. An attacker can use Information Disclosure for revealing additional information (system data, debugging information, etc.) which will help to learn more about the system and to plan other attacks. It is recommended to install this SAP Security Note to prevent risks.



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.

First of all, let’s have a few moments of silence in remembrance of SSL now that SSL is officially dead.


Long live TLS!


That said, even though a lot of SAP customers are relying on HTTPS (TLS) to ensure the confidentiality of data in motion in their Fiori applications over public networks, there are still fundamental weaknesses in even TLS that make data disclosure possible in a man in the middle attack. Consider the attack scenario in the next section.



Man in the Middle TLS Attack Scenario

The conversation in a well-behaved man in the middle  conversation to your Fiori Gateway Server (with, say, your local Starbucks WiFi hotspot as the man in the middle) should look something like the following:



The well-behaved man in the middle simply routes all requests to the server, without inspecting or modifying that traffic, and routes responses from the server back to the client.


Now, an attacker seeking to inspect that traffic could simply drop the request on the floor and forge a redirect – which would look something like the following:


This has the effect of forcing future communication to the Fiori Gateway Server to the unencrypted HTTP protocol, allowing the attacker to inspect all traffic to the NetWeaver Gateway unencrypted. An attacker would have the luxury of viewing payment details and other types of confidential data in clear text.



Most supported Fiori web browsers and the Fiori client will not warn the user of the change from HTTPS to HTTP – the user would need to pay close attention to the browser's encryption "lock" icons. Some browsers (think Chrome) will issue strong warnings that alert the user to the fact that the session is being downgraded to an HTTP session, but even then many users may err on the side of  “getting things done” and ignoring any warning messages.


Likelihood of this Scenario

When measuring risk, it helps to remember that Risk = Impact * Likelihood. In the past, man-in-the-middle attack scenarios were considered esoteric or difficult to pull off - a low-likelihood scenario. Today, with the ubiquity of WiFi, this is no longer the case. In fact, an attacker with limited technical knowledge can buy a $100 Pineapple device to take advantage of this particular vulnerability. Given these attacks can be pulled off by unsophisticated users with minimal investment, the likelihood of this type of man-in-the-middle attack is orders of magnitude higher than it was even 5 years ago.



Strategies for SAP Customers to Secure Data in Motion in Fiori Applications

This said, there are several approaches SAP customers can take to address this risk when rolling out Fiori to devices on public networks to address this specific risk. These include:

  1. Blocking access to the HTTP port on your NetWeaver Gateway server at the firewall. This is possibly the cheapest alternative available to SAP customers.
  2. Implementing HTTP Strict Transport Security. This requires some modification to standard Fiori to implement and requires browsers that support HSTS. Unfortunately, not all browsers support HSTS and so this option may not be effective in BYOD-scenarios
  3. Requiring that remote devices access your Fiori Launchpad over VPN. VPN tunnels can’t be negotiated down to an “unencrypted” version. Currently, the only known way attackers can attack VPN connections is to forge reset packets to drop the tunnel, in the hope that a user will give up using VPN and will try a less secure option.  On the negative side, VPN tunnels add to authentication complexity.
  4. Implementing SAP Application Protection by Mocana. This is a great offering that handles a host of security issues, including the specific man-in-the-middle attack scenario discussed here. This solution was designed to run applications securely on untrusted devices, protecting data at rest and in motion. A key feature of SAP Application Protection by Mocana is VPNs initiated from the application, so that an attacker doesn’t have the opportunity to inspect unencrypted data in motion even if they have control of the device.  And, Mocana-wrapped applications can take advantage of certificate-based authentication to reduce authentication complexity to both the Gateway and the Atlas VPN appliance.
  5. SAP Customers running the Afaria MDM solution have the ability to implement policies on devices to ensure WiFi connections are only to trusted networks, or can disable WiFi altogether (controlled by the policies “Connect to Specific APs” or “Get current WiFi AP’s SSID”). Many other MDM tools have similar capabilities. Again, this is not always possible to enforce in a BYOD scenario.
  6. Implementing HTTPS Everywhere plugins for all clients. Unfortunately, as of this writing this is not a viable option in a mobile device scenario.



Industry Initiatives to Address this Risk

There are several initiatives underway to address this scenario, all in various stages of adoption.

  • HTTPS Everywhere – this is a browser plugin that always attempts to connect to the web server/service via HTTPS, regardless of the link or redirect information presented.
  • HTTPS Transport Security Protocol (HSTS)
  • Deprecate HTTP altogether and encrypt all web traffic

Unfortunately given the sheer number of internet-enabled servers and clients, I don’t see any of these making significant headway to addressing this issue internet-wide in a timely manner.



SSL is dead: https://www.ciso-central.org/transport-layer-security/ssl-is-dead-long-live-tls

OS/Browser combinations supported by Fiori: http://service.sap.com/sap/support/notes/1931218

Great blog on HTTP Strict Transport Security in SAP applications: http://scn.sap.com/community/labs/blog/2014/04/26/http-strict-transport-security-hsts

Listing of HSTS Supported Browsers: http://caniuse.com/#feat=stricttransportsecurity

Generic info on SAP Application Protection by Mocana: http://www.sap.com/pc/tech/mobile/software/solutions/emm/secure-apps.html

Blog on deprecating HTTP: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

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


Filter Blog

By author:
By date:
By tag: