Data Security in Web Applications

Caution Caution

Only data that the user is also allowed to see can be sent from the Web Dynpro application to the client (Web browser).

End of the caution.

This also applies if the data is normally not visible to the user on the interface.

All of the data sent to the client (HTTP response) can be accessed by means of simple aids, which are available to anyone. These include, for example, HTTPWatch, Fiddler, or the DOM Explorer.

Caution Caution

All of the data sent from the client to a Web Dynpro application can be manipulated.

End of the caution.

Data sent from the client to a Web application (HTTP request) can easily be manipulated. An additional tool can also be used, for example, to address an application in an unexpected manner by entering a manipulated URL or JavaScript (javascript: ) in the address line of the Web browser.

These attacks can be carried out primarily by the user of the application. However, there are also complex scenarios such as “foisting” a Web site that sends data to the Web application (XSRF) through the user’s access, while remaining “invisible” to the user.

Specific scenarios in Web Dynpro ABAP are described below, for which both rules (warnings) are particularly important.

Security of Application/URL Parameters

When starting a Web Dynpro ABAP application, you can transfer URL parameters, which, apart from a few exceptions, can be read by the application in the startup plug. The same applies when resuming an application with the resume plug.

If the name of a URL parameter matches the name of an application parameter, the parameter value specified in the application is overwritten by the URL parameter value.

Parameter values have to be checked by the application itself. The Web Dynpro Framework does not perform any kind of check. The type, value range, and if necessary, plausibility and authorization have to be checked by the application.

The data must be handled as though the user had entered it manually.

Data Security for Exit Plug and Portal Navigation

The parameters specified when the exit plug is called or in portal navigation are sent to the starting application via the client.

For this reason, the parameters must not contain any data that the user is not allowed to see.

Data Security for Portal Eventing

Since the data is sent from application A to application B via the Web browser, the same statements apply as for URL parameters.

Data that the user should not see must not be transferred via portal eventing.

The data must be handled by the recipient as though the user had entered it manually. If necessary, the type, value range, plausibility, or authorization may have to be checked and the data converted since this is not carried out by the Web Dynpro Framework.

Data Security for CHIP Inports and Outports

Parameters for inports and outports must be handled in the same way as start and resume parameters.

Data that the user should not see must not be transferred via inbound and outbound plugs.

The data must be handled by the recipient as though the user had entered it manually. If necessary, the value range, plausibility, or authorization may have to be checked since these are not checked by the Web Dynpro Framework.

MIME Objects:

Web Dynpro provides a function to save MIME objects in a Web Dynpro ABAP component. These files can be used in Web Dynpro ABAP applications by using an HTTP acccess. The MIME object is saved after the first access in the browser cache. If you want to avoid this caching, delete all the values for the expiry time in the MIME object and remove the switch "Expiry Time Active". The switch "Individual Expiry Times" must be activated.

Explanations of the Checks

Check	Description
Type check	URL and application parameters are handled as character-type data. For example, it is not possible to define application parameters of integer type. This means that a `MOVE` into an integer field can lead to a `CX_SY_MOVE_CAST_ERROR` exception. This should be caught by the application developer.
Value range check	A check must also be carried out to determine not only whether the value can be converted into the target type, but also whether it is valid. For example, `X` and `SPACE` for Boolean values.
Plausibility check	A check has to be carried out to determine whether the input is plausible and possible in certain circumstances.
Authorization check	A check has to be carried out, for example, to determine whether the user is allowed to perform the requested action or display the object specified.