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 / XML | out = escape(val = val format = cl_abap_format=>e_xss_ml). |
| JavaScript | out = escape(val = val format = cl_abap_format=>e_xss_js) |
| URL | out = escape(val = val format = cl_abap_format=>e_xss_url) |
| CSS | 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 | Method |
| HTML / XML | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML(val) |
| JavaScript | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_JAVASCRIPT(val) |
| URL | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_URL(val) |
| CSS | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_CSS(val) |
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“%>
<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)
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.
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: <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()
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
Comments