'[FD] Securing SAP Systems from XSS vulnerabilities Part 2: Defense for SAP NetWeaver ABAP'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    [FD] Securing SAP Systems from XSS vulnerabilities Part 2: Defense for SAP NetWeaver ABAP
From:       Darya Maenkova <d.maenkova () erpscan ! com>
Date:       2015-06-24 18:03:39
Message-ID: 558AF0FB.2070608 () erpscan ! com
[Download RAW message or body]

     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 [4].

      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 page directives: /<%@page language="abap" 
forceEncode="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)

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:

oRelease 6.40-7.11: ~auto_html_escaping=1 and ~new_xss_functions=1 
oRelease >=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 potentialattack 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

oset LOGFILE valueto path_to_file

oSе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.

oSet FILEWRAP value tooff. Old log files will be saved for future analysis

•Configure*/icm/security_log/* parameter, oset LOGFILE valueto 
path_to_fileoset VERBOSITY value to 3. To be able to save all necessary 
data inoSet FILEWRAP value to off. Old log files will be saved for 
future analysis

-- 
<https://www.linkedin.com/company/2217474?trk=ppro_cprof> 
<https://twitter.com/erpscan>

<http://erpscan.com/>

------------------------------------------------------------------------

e-mail: d.maenkova@erpscan.com <mailto:d.maenkova@erpscan.com>

address: 228 Hamilton Avenue, Fl. 3, Palo Alto, CA. 94301

phone: 650.798.5255

erpscan.com <http://erpscan.com>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[prev in list] [next in list] [prev in thread] [next in thread] 