Security Issues in Web Dynpro for ABAP 

When creating Web applications using Web Dynpro for ABAP programming models, and for the scenario variant Developing ABAP Applications Using Web Dynpro, it is important to consider security issues. Security functions are available both for when you create Web applications as well as for when you operate them.

In a productive system the following HTTP service nodes (transaction SICF) are not active for the configuration, since a configuration always represents a development.

●        /sap/bc/webdynpro/sap/CONFIGURE_APPLICATION

●        /sap/bc/webdynpro/sap/CONFIGURE_COMPONENT

●        /sap/bc/webdynpro/sap/WD_ANALYZE_CONFIG_APPL

●        /sap/bc/webdynpro/sap/WD_ANALYZE_CONFIG_COMP

●        /sap/bc/webdynpro/sap/WD_ANALYZE_CONFIG_USER

Security in AS-ABAP

For basic information about security aspects in the AS ABAP system in which you are creating your Web application, see Network and Communication Security and SAP Web Application Server Security (ABAP).

Note in particular the configuration for SSL support.
The logon ticket cache function is provided for increasing performance when there are multiple logons.

Certain virus scan profiles are delivered by SAP in the standard system. A virus scan can be performed when uploading HTTP (more information: Virus Scan Interface).

The Internet Communication Manager (ICM) receives the HTTP requests from the Internet and returns a response.

Logging on to Web Applications

To access a Web application, AS ABAP uses the HTTP framework from the Internet Communication Manager (ICF), which provides functions for logging on to AS ABAP.

Refer to Activating and Deactivating ICF Services. For security reasons, the only services that should be active in the HTTP service tree are those services that you really need. If, however, you activate nodes at a higher level, this means that the whole part of the service tree below this level is also active and completely open, and therefore not secure if, for instance, an anonymous user is defined.

A simple procedure is available for developing and configuring the system logon with Web applications. The security aspects are integrated in this procedure.

Web Applications Without Domain Relaxing

Before NW 7.0 SP6, a Web Dynpro application could not be run isolated in an environment (for instance, in the portal), since it always relaxed the domain in its environment. However, for applications where security is critical this opens up a gateway for attack. Attackers could run their own application in a different IFrame, relax their domain too, and access sensitive data from the original application.

To ensure this does not happen, the new WDPROTECTEDAPPLICATION application parameter can be set for an application on the server, regardless of whether the application relaxes its domain or not.

The standard setting is where the domain remains relaxed. The parameter is used to deactivate this standard setting for applications where security is critical.

Check for which of your applications security is critical and set the indicator in the Web Dynpro application accordingly. To do this select the Web Dynpro application in SE80 and go to the Parameters tab page. Use F4 help for the parameter to select the entry WDPROTECTEDAPPLICATION and set its value to X.

Web Dynpro Console

If sap-wd-ssrconsole is set to true, the Web Dynpro console is displayed. This contains various information such as the build number of the rendering, the version in use, and other information to support error handling. No data can be input.

In contrast to the console in Web Dynpro for Java, the console in Web Dynpro ABAP is used for displaying data only.

Security of View Context Data

SAP recommends that the view context should contain only the data necessary for the special view. Regardless of security issues, a design like this also improves application performance.

The data held and processed in the view context is a central part of every Web Dynpro application. The UI elements that were defined for the relevant view using the View Designer are generally bound to the individual view context elements by the Web Dynpro application developer to ensure that data flow takes place between the client and the server. However, it is also possible for view context data to be unbound in the view contexts, since, for instance, an ABAP Dictionary structure containing further attributes that are not visible is used.

To improve the security, you can either set the attribute to readOnly = true in the Properties view or delete the relevant attributes. Unauthorized access through the client to the content of the view context is not possible with server side rendering due to various security mechanisms, but can never be ruled out (because of software errors). Hence the recommendation above that the view context should only contain data that is not critical if changed.

Also note that all input always has to be checked. Web Dynpro already provides an inbuilt check for type security. In addition, an application must check the semantic correctness of each changed attribute. This includes checking specific types of attacks, such as SQL attacks, if an input is used later in a dynamic SQL statement.

Security for FileUpload

See Security Notes for FileUpload UI Elements

Security for Attributes of UI Elements

Not all attributes of UI elements must be bound. A constant value is also allowed. The point here is that during the rendering the content of such attributes escapes, so that an attack can be eliminated in this way. The attribute ID of an element has a special significance here. This is converted in Web Dynpro for ABAP into a hexadecimal number with a random offset, which means that a direct assignment to a UI element is no longer possible (see also Data Binding of User Interface Element Properties).

Security for Events of UI Elements

In an SSR client, only events that can be triggered by user interaction can also be triggered using a JavaScript attack. The UI element associated with each event arriving on the server is checked to ensure that it is visible and enabled. Certain events also restricted by the readOnly attribute in the UI element when they are being executed. In such cases, this is also checked.

Security of URL Parameters

An application can define its own URL parameters. The content of these parameters should be checked by the application to avoid any attacks occurring this way. URL parameters provided by Web Dynpro are automatically checked by the Web Dynpro runtime.

Authorizations

General authorization checks for services and application are available over the ICF (see Authorizations).

Special authorization checks for Web Dynpro Applications if needed are assigned by the respective application.

An authorization check is only offered by Web Dynpro for personalization. This checks the administration authorization for personalizing UI elements.

Application Logoff Page

You can use your own logoff page for your Web Dynpro application: Application Logoff Page

Application Error Pages

You can suppress the standard error page generated by the ICF and define your own error page instead: Application Error Page

Security Risk List

A white list infrastructure in the HTTP framework fends off XSS attacks. Security Risk List

URL Generation

See URL Generation in an AS-ABAP - Web Dispatcher Configuration

Security for Portal Integration

For security reasons, we recommend that you use SAP logon tickets or X.509 certificates for portal integration. Other logon procedures are not fully supported.

Notes

Relevant SAP notes

SAP Note Number	Title
517484	Inactive Services in the Internet Communication Framework
510007	Setting up SSL on the Web Application Server
420085	Logon Ticket Cache
853878	HTTP White-List Check (Security)