Show TOC

Background documentationSecurity Risk List

 

In some situations a framework or an application on the ABAP server may have received information from an external system, which is then used in further processing steps in the course of interaction with the browser. This external information may link to a Web site that cannot be trusted. The following startup URL serves as an example:

/myApplication?use-css-file=http://our.company.portal.com/ourTheme.css

Usually, the myApplication application uses the string specified for use-css and renders it from within the HTML page that was sent to the browser in order to load this specific style sheet. The following or a similiar sequence is displayed in HTML:

<html>

    <header>

         <css src=” http://our.company.portal.com/ourTheme.css”>

As a result the browser loads this alternative CSS file from the enterprise portal.

CSS files can however also contain and execute JavaScript files. Let's assume that a startup URL like this is available in the Internet or sent by e-mail in the following format:

/myApplication?use-css-file=http://some.unknown.site.com/full.of.JavaScript.css

If the myApplication application now takes the string specified for use-css and renders it in HTML to the browser, an CSS file is loaded as soon as a user clicks on the link. In certain circumstances, the CSS file can execute an unknown JavaScript code.

How does the myApplication application know that the value specified for use-css lies within a valid value range (on a trusted server or references a server in a trusted domain)? In this case the whitelist infrastructure enables the application to verify that the value for use-css lies within a trusted value range.

Table HTTP_WHITELIST

The security risk list or whitelist enables URL-like parameters from the portal to be integrated into AS-ABAP. Method CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST is provided for this.

The whitelist is actually only a passive infrastructure, and does not execute any tasks that carry security risks. The whitelist is a memory that applications or frameworks use to verify that received data can be assigned to configured data in a valid value range. Each application and each framework must, however, check the parameters that are set externally and can be used to execute browser renderings. The application uses the API call to verifiy that the received data is valid.

A similar example would be an exit URL, which the application navigates to once a task has been completed.

/myApplication?exit-target=http://competitor.com/we.are.better.html

If an exit URL is created and stored in the Internet, the application is prompted to navigate to unknown target URLs.

In all these scenarios the application or the framework must ensure that all received data and information is validated before it is used. With functions provided by the central framework, the framework must verify these special URL parameters against the whitelist, and ascertain whether the parameters lie within a valid value range. If Business Server Pages (BSP) are used as the framework, these externally set parameters (sap-exiturl, sap-themeRoot) are validated before they are used. If a BSP application has additional parameters that behave similarly, the application has to validate these parameters itself.

So patterns are configured in the whitelist and URLs from external sources are verified against them. This process verifies that these URLs can be accepted. The whitelist is stored in table HTTP_WHITELIST, which can be changed in transaction SE16.

Each table record has the following structure:

  • entry_type

    URL type to be compared with this entry.

    Example: CSS off-box reference

    There are the following types of entry_type:

    entry_type

    Whitelist Entry

    Description

    01

    for Portal CSS theme URL

    02

    for sap-exiturl

    03

    for NetWeaver Business Client (NWBC)

    10

    for Web Dynpro Resume URL

  • host

    Host name that is compared with the inbound host. This field is empty if the host name is not checked for a specific entry. The placeholder (*) can be used.

  • protocol

    Protocol to be checked. Usually this is HTTP or HTTPS. This field can be empty if no check is to be made.

  • port

    Port number to be checked. Can only consist of digits, be empty, or 0 for no check (corresponds to the asterisk *).

  • url

    URL for checking the inbound URL. The placeholder (*) can be used. The url corresponds to the absolute path.

If there are no entries in table HTTP_WHITELIST, no checks are made.

As soon as the URL with its separate parts is available, the table is compared with the whitelist. This table also contains the separate parts of the URL, which are compared one after the other.

With the entry-type, various types of whitelists can be configured. Usually the server from which CSS themes can be loaded is defined in the whitelist. These CSS themes are loaded by generating a URL pointer in the HTML that is supplied with the themes and that leads back to the portal server.

If no parameters are specified, then none are checked. It is assumed that they are correct.

If a masking character (*) is specified, it is compared to the received string.

URL Examples

URL

Standard Port/Standard Root

http://myHost.myDomain.myExt:1080/myUrl

http://myHost.myDomain.myExt/myUrl

Standard port 80

https://myHost.myDomain.myExt/myUrl

Standard port 443

http://myHost.myDomain.myExt:1080

Standard root URL

http://myHost.myDomain.myExt

Standard root URL

/myUrl

No host data specified

Example Example

whitelist-protocol = (empty string)

This implicitly means that the protocol is not checked. All URLs in the form http[s]://... or /... are allowed through as no check is made whether a protocol has been set.

End of the example.

Example Example

whitelist-protocol = *

The protocol is checked whether any value has been defined for it. All URLs in the form http[s]://... are allowed through. URLs in the form /... are however not accepted as according to this rule no protocol is available.

End of the example.

Example Example

whitelist-protocol = https

Only URLs in the form https://... are allowed through.

End of the example.

The most simple case is to use a whitelist with empty fields and not to make any checks. The purpose of the whitelist table is however to offer a level of security that is required by customers.

For instance you could have a portal server that provides URLs that point to the portal themes (CSS files). For the first security level you could use a whitelist filter in the following form:

Syntax Syntax

  1. protocol=*, host=*.myDomain.myExt, port=*, url=
End of the code.

With this all references to another computer in the same domain would be accepted.

A scenario is also possible that restricts the load to just this one portal server. This would look like:

Syntax Syntax

  1. protocol=*, host=myPortal.myDomain.myExt, port=*, url=
End of the code.

In this case there are various security loopholes. For example, another Web server can be installed on the same portal server. The portal server is secure, but not necessarily the Web server. The URLs would still pass through the whitelist. However, you require a default entry with which only the URLs from the portal server are accepted. You should therefore always specify the protocol as well as the port specifications:

Syntax Syntax

  1. protocol=http,  host=myPortal.myDomain.myExt, port=1080, url=/*
  2. protocol=https, host=myPortal.myDomain.myExt, port=1443, url=/*
End of the code.

Caution Caution

By default the whitelist table is empty and no checks are made. We strongly recommend that you create some rules, otherwise the use of this functionality is vulnerable to malicious URLs.

End of the caution.

Caution Caution

Note that the latest version of method CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST processes rules slightly differently than previous versions and this can lead to problems with applications developed with older versions of this method.

For more information, see SAP Note 1594641Information published on SAP site.

End of the caution.

Note Note

Version 7.31: Changes to method CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST are always enabled.

Previous versions: Changes to method CL_HTTP_UTILITY=>IF_HTTP_UTILITY~CHECK_HTTP_WHITELIST are deactivated by default and can be enabled or disabled by a profile parameter.

End of the note.
Method CHECK_HTTP_WHITELIST

This method checks whether a received URL matches with a white list stored in a local database. The URL, which serves as an input parameter, is either an absolute URL or a server-specific absolute URL.