Checking User Input for Program Commands

If Internet pages permit user input, there is a danger that malicious users (attackers) will use improper input to gain access to other users' data.

To do this, an attacker uses the cross-site scripting weakness of a server; that is, the server accepts user input and forwards these to other browsers unchecked and unfiltered. This means that a harmful program of the attacker's could be contained in the input that is sent to an Internet page and is seen there by users as a normal program of this page. The victim therefore believes that the program originates from the trustworthy Internet page and therefore permits its execution. When the victim accesses the (trustworthy) Internet page, the harmful program is executed in the victim's browser (code injection) or data input by the victim is redirected to the attacker and only then forwarded to the normal server.

Stealing Cookies with Cross-Site Scripting

Process Flow

Process of the Attack

  1. The user follows a link, for example, in a forged e-mail, to a trustworthy page, whose URL the attacker has extended with JavaScript.

    Due to the JavaScript in the URL, the user initially goes, unintentionally, to the attacker's page.

  2. Only then is the user forwarded to the page that he or she actually wanted to call.

  3. Since trusted page has an XSS weakness, it does not check the user input. It therefore forwards the command for sending a cookie contained in the URL to the user's browser without checking it.

  4. The user trusts the trusted page and permits its script requests. Due to the URL parameters, it appears as though the cookie request originates from the trusted page. The user therefore sends his or her cookie. However, the attacker receives the cookie due to the forwarded script command.

  5. The attacker can then use the stolen cookie to log on to the trusted page with the identity of the user, as long as the cookie is valid.

SAP Measure

A countermeasure against cross-site scripting (XSS) is to check the user input that is sent to the server as an HTTP request. The filtering of the input stream should prevent an attacker from sending damaging programs to the applications running on the server. Filtering the input stream is an effective and easy-to-use countermeasure. This approach is also largely independent of the respective Web application. The input is filtered using a standard pattern , which you can change if necessary.

For more information, see Patterns.

By default, this filter is activated in SAP systems, to provide the maximum possible security. The relevant profile settings are:

  • csi/enable =1

  • csi/SAP/csa_lib = sapcsa.dll or libsapcsa.so

  • icm/HTTP/auth_0= PREFIX=/, FILTER=SAP

You can deactivate the filter as follows (for example, if an application requires the input of script tags):

  • Set the profile parameter csi/enable to the value 0 in transaction RZ11. You can also use prefixes to filter individual paths (for example, if users enter data there) or exclude individual paths from filtering (for example, is users cannot enter any data there). value is immediately active and you should therefore use this method.

  • Set the parameter icm/HTTP/auth_0 of the Internet Connection Manager (ICM) to an empty value in transaction RZ11. After you have changed the settings of the profile parameters, you need to restart the Internet Connection Manager using transaction SMICM.