1. No category

W h i t e Pa p e r
SECURING SAP SYSTEMS FROM
XSS VULNERABILITIES
Dmitry Chastuchin
Sultan Abubakirov
Alexander Polyakov
www.erpscan.com
Table of Contents
Introduction................................................................................................... 4
Attack............................................................................................................. 5
Stored XSS...................................................................................... 5
Reflected XSS.................................................................................. 6
DOM XSS. ........................................................................................ 6
General Defense ........................................................................................... 7
Defense for SAP NetWeaver ABAP................................................................ 8
From the developer’s perspective.. .................................................. 8
From the administrator’s perspective............................................ 12
From incident response perspective.............................................. 13
Defense for SAP NetWeaver J2EE................................................................ 14
From the developer’s perspective.. ................................................ 14
Defense for SAP HANA XS .......................................................................... 18
From the developer’s perspective.. ................................................ 18
From the administrator’s perspective............................................ 18
From incident response perspective.............................................. 18
About ERPScan............................................................................................. 20
About ERPScan Research............................................................................. 21
References................................................................................................... 22
Securing SAP Systems from XSS Vulnerabilities
3
Introduction
628
XSS vulnerabilities
were found in SAP
products
22%
In this whitepaper, we are 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).
of all
vulnerabilities
found in SAP
products are XSS
vulnerabilities
52
XSS vulnerabilities
were discovered
by ERPScan
researchers
4
ERPScan
Attack
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.
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).
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 filesw, his browser executes malicious code uploaded by the
attacker.
When after attack a legitimate user requests some information,
such as a list of files, his browser executes malicious code uploaded
by the 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
Securing SAP Systems from XSS Vulnerabilities
5
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 this price.
Reflected XSS
In this case malicious code is not stored on a server but is executed by the victim user at the very
moment he opens malicious link such as:
http://example.com/search.php?q=<script>DoSomething();</script>
In this case, to exploit vulnerability we need to somehow send a link for the exploit to the victim. This
type of XSS is less powerful because it requires user interaction, but it is 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.
DOM XSS
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.
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>
6
ERPScan
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.
• 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.
Now, let’s look in detail at the description of how to secure different SAP Applications from XSS.
Securing SAP Systems from XSS Vulnerabilities
7
Defense for
SAP NetWeaver ABAP
Questions?
Comments?
Brilliant ideas?
We want to hear
them. Drop us a
line at
[email protected]
find us on LinkedIn,
or tweet @erpscan
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 / XML
JavaScript
URL
CSS
out = escape(val = val format = cl_abap_format=>e_xss_ml).
out = escape(val = val format = cl_abap_format=>e_xss_js)
out = escape(val = val format = cl_abap_format=>e_xss_url)
out = 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.
Context
HTML / XML
JavaScript
URL
CSS
Method
out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML(val)
out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_JAVASCRIPT(val)
out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_URL(val)
out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_CSS(val)
For more information about the delivery of these extensions, see SAP
Security Note 1582870 [4].
8
ERPScan
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
[5] and SAP Security Note 1638779 [6]. 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 following page directives: <%@page language="abap" forceEnco
de="html|url|javascript|css"%>
After importing SAP Security Note 1600317 [7], 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"%>
<html><body><form>
<% data: inputvalue type string.
inputvalue = request->get _ form _ field( ‘x’ ).
%>
<input type=text name=x value="<%=inputvalue%>">
<input type=submit>
</form></body></html>
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)
Securing SAP Systems from XSS Vulnerabilities
9
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.
Example:
<script>
var msg = ‘<otr>Hello</otr>’;
</script>
<input name=xyz value="<otr>Replace ‘dog’ with ‘cat’</otr>">
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 = ‘<otr>Hello</otr>’;
alert(msg);
</script>
JavaScript example
<%@page language="abap" forceEncodeOtr="html"%>
<script>
var msg = ‘<%JavaScript=<otr>Hello</otr>%>’;
alert(msg);
</script>
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:
10
ERPScan
<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)
...
</htmlb:content>
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%>"/>
...
</htmlb:content>
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()
Securing SAP Systems from XSS Vulnerabilities
11
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
◦◦ 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 [8].
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 [9].
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 clientside scripts, applets, plugins, and the like. Set httpOnly flag to secure cookies and Logon Tickets from
transmitting them into malicious host using XSS vulnerability.
12
ERPScan
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: if
• 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,
◦◦ 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
Securing SAP Systems from XSS Vulnerabilities
13
Defense for
SAP NetWeaver J2EE
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):
14
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)
ERPScan
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)
<head>
<title>[CASE1]</title>
</head>
<table>
<tr>
<td>Username</td>
<td>[CASE1]</td>
</tr>
</table>
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]’>
</form>
<a name=»[CASE2]»>Click here</a>
CASE3 (Output is a URL)
<a href=»CASE3» style=»[CASE3]»><img src=»[CASE3]»
lowsrc=»[CASE3]»></a>
CASE4 (Output inside a SCRIPT context, but output is not a string declaration)
<script>
var a = [CASE4];
[CASE4];
</script>
CASE5 (Output is a string declaration in a script)
<script>
var a = ‘[CASE5]’;
alert(«[CASE5]»);
</script>
The class name is XSSEncoder (class name with package name: com.sap.security.core.server.csi.XSSEncoder).
Securing SAP Systems from XSS Vulnerabilities
15
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.
The methods to use for each context are:
Context
HTML /
XML
JavaScript
URL
CSS
Method
out = XSSEncoder.encodeHTML( in ) and XSSEncoder.encodeXML( val );
out = XSSEncoder.encodeJavaScript( val );
out = XSSEncoder.encodeURL( val );
out = 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 plugin in framework/_core/src/main/js/jquery.sap.encoder.js.
The functions to use for the different contexts are:
Context
HTML / XML
JavaScript
URL
CSS
Function
jQuery.sap.encodeHTML(sValue) and jQuery.sap.encodeXML(sValue)
jQuery.sap.encodeJS(sValue)
jQuery.sap.encodeURL(sValue)
jQuery.sap.encodeCSS(sValue)
From the administrator’s perspective
The administrator have to set the parameters to improve security:
• Global _ app _ config/session _ config/sessionTimeout = 900. Enable session timeout to
minimize potential attack window.
16
ERPScan
• 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.
Securing SAP Systems from XSS Vulnerabilities
17
Defense for SAP HANA XS
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
18
ERPScan
◦◦ 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. [14]
Whant to find out more?
Check out our annual report
‘‘Analysis of 3000 vulnerabilities in
SAP’’
Download the full report and other
resources from:
erpscan.com/white-papers
Securing SAP Systems from XSS Vulnerabilities
19
About ERPScan
ERPScan is the most respected and credible Business Application Security provider. Founded in 2010,
the company operates globally. Named as an ‘Emerging vendor’ in Security by CRN and distinguished
by more than 25 other awards - ERPScan is the leading SAP SE partner in discovering and resolving
security vulnerabilities. ERPScan consultants work with SAP SE in Walldorf supporting in improving
security of their latest solutions.
ERPScan’s primary mission is to close the gap between technical and business security, and provide
solutions to evaluate and secure ERP systems and business-critical applications from both, cyberattacks as well as internal fraud. Usually our clients are large enterprises, Fortune 2000 companies and
managed service providers whose requirements are to actively monitor and manage security of vast
SAP landscapes on a global scale.
Our flagship product is ERPScan Security Monitoring Suite for SAP. This multi award-winning innovative
software is the only solution in the market certified by SAP SE covering all tiers of SAP security i.e.
vulnerability assessment, source code review and Segregation of Duties. The largest companies from
across diverse industries like oil and gas, banking, retail, even nuclear power installations as well as
consulting companies have successfully deployed the software. ERPScan Monitoring Suite for SAP is
specifically designed for enterprise systems to continuously monitor changes in multiple SAP systems.
It generates and analyzes trends on user friendly dashboards, manages risks, tasks and can export
results to external systems. These features enable central management of SAP system security with
minimal time and effort.
We use ‘follow the sun’ principle and function in two hubs, located in the Netherlands and the US
to operate local offices and partner network spanning 20+ countries around the globe. This enables
monitoring cyber threats in real time while providing an agile customer support.
20
ERPScan
About ERPScan Research
The company’s expertise is based on the research subdivision of ERPScan, which is engaged in
vulnerability research and analysis of critical enterprise applications. It has achieved multiple
acknowledgments from the largest software vendors like SAP, Oracle, Microsoft, IBM, VMware, HP for
exposing in excess of 400 vulnerabilities in their solutions (200 of them just in SAP!).
ERPScan researchers are proudly to expose new types of vulnerabilities (TOP 10 Web hacking
techniques 2012) and were nominated for best server-side vulnerability in BlackHat 2013.
ERPScan experts have been invited to speak, present and train at 60+ prime international security
conferences in 25+ countries across the continents. These include BlackHat, RSA, HITB as well as
private trainings for SAP in several Fortune 2000 companies.
ERPScan researchers lead project EAS-SEC, which is focused on enterprise application security research
and awareness. They have published 3 exhaustive annual award-winning surveys about SAP Security.
ERPScan experts have been interviewed by leading media resources and specialized info-sec
publications worldwide, these include Reuters, Yahoo, SC Magazine, The Register, CIO, PC World,
DarkReading, Heise and Chinabyte to name a few.
We have highly qualified experts in staff with experience in many different fields of security, from web
applications and mobile/embedded to reverse engineering and ICS/SCADA systems, accumulating their
experience to conduct research in SAP system security.
Securing SAP Systems from XSS Vulnerabilities
21
References
1. Analysis of 3000 vulnerabilities in SAP http://erpscan.com/wp-content/themes/supercms/
Publications/3000-SAP-notes-Analysis-by-ERPScan.pdf
2. SAP Security Note 1284360 http://service.sap.com/sap/support/notes/1284360
3. SAP Security Note 1788080 http://service.sap.com/sap/support/notes/1788080
4. SAP Security Note 1582870 http://service.sap.com/sap/support/notes/1582870
5. SAP Security Note 1600317 http://service.sap.com/sap/support/notes/1600317
6. SAP Security Note 1638779 http://service.sap.com/sap/support/notes/1638779
7. SAP Security Note 1600317 http://service.sap.com/sap/support/notes/1600317
8. SAP Security Note 1488500 http://service.sap.com/sap/support/notes/1488500
9. SAP Security Note 916255 http://service.sap.com/sap/support/notes/916255
10.SAP Security Note 866020 http://service.sap.com/sap/support/notes/866020
11.SAP Security Note 1601461 http://service.sap.com/sap/support/notes/1601461
12.SAP Security Note 1590008 http://service.sap.com/sap/support/notes/1590008
13.Logging additional information http://help.sap.com/saphelp_nw70/helpdata/en/d8/4134420793ab04e100
00000a1550b0/content.htm?frameset=/en/ef/8cd7f51dfead42ab90537886104269/frameset.htm&current_
toc=/en/49/e98876e9865b4e977b54fc090df4ed/plain.htm&node_id=154
14.ABAP protection SAP Encoding Functions for AS ABAP http://help.sap.com/SAPhelp_nw70/helpdata/en/a6/
87890ae991441b89bf418d0198ddcc/content.htm
15.Java protection http://help.sap.com/javadocs/nwce/current/se/com.sap.se/com/sap/security/core/server/
csi/util/StringUtils.html
16.SAP Encoding Functions for AS Java and JavaScript http://help.sap.com/SAPhelp_nw70/helpdata/en/b5/
b5b54ba97d4413987252fed5866603/content.htm?frameset=/en/16/58ece980104b668cfe69b23dc925c3/
frameset.htm&current_toc=/en/44/6ad7e1e5254ddee10000000a1553f7/plain.htm&node_id=39
17.Prevention of Cross-site Scripting SAP HANA protection https://sapui5.hana.ondemand.com/sdk/docs/guide
/4de64e2e191f4a7297d4fd2d1e233a2d.html
18.Protecting SAP® Applications Based on Java and ABAP™ Against Common Attacks https://websmp104.sapag.de/~sapdownload/011000358700001376952010E/Protecting-SAP-Apps.pdf
22
ERPScan
Securing SAP Systems from XSS Vulnerabilities
23
Our Contacts
Global Headquarters: 228 Hamilton Avenue, Fl. 3,
Palo Alto, CA. 94301
Phone: 650.798.5255
EMEA Headquarters: Luna ArenA 238 Herikerbergweg,
1101 CM Amsterdam
Phone: +31 20 8932892
Twitter: @erpscan
Web: www.erpscan.com
Contact: [email protected]
PR: [email protected]