Social Network For Security Executives: Network, Learn & Collaborate
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.
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:
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).|
|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.
|HTML / XML||out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML(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 .
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  and SAP Security Note 1638779 . These BSP page attributes have the advantage that the BSP framework ensures that the most secure version of encoding is used.
After importing SAP Security Note 1600317 , 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%>“>
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):
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)
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“%>
<script> var msg =
<%@page language=“abap“ forceEncodeOtr=“html“%>
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:
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:textView text=“<%=param%>“/> (1)
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.
In the following example, the directive to do HTML encoding is ignored, instead of the htmlb tag decides internally which encoding is appropriate.
For Internet Transaction Server (ITS) and HTML Business
For the Internet Transaction Server (ITS) and HTML Business, the following encoding functions are available:
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:
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:
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 .
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 .
For Manual Encoding
You can also manually encode output by using the functions named above. In this case, encode all output.
The administrator has to set the parameters to improve security:
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.
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.