Security Aspects of Web Dynpro for Java 

When you are developing or running Web Dynpro programs, it is important that the available security functions are integrated, as is also the case for other Web applications. With regard to the security-relevant aspects of a Web Dynpro application, the following categories can be identified:

●      Development Mode

●      Web Dynpro Console

●      Authentication

●      Model Import

●      View Context Data

●      Front-End

●      Modifiable User Interface Elements

●      Generated URLs by the URL Generation Service

●      URL Parameters

●      Passwords

●      Web Dynpro Applications in the SAP NetWeaver Portal

●      Logical Systems

Development Mode

The DevelopmentMode parameter is used to distinguish between development and productive systems. SAP initially decided to set up a system initially with the DevelopmentMode activated so that a system that is set up quickly can easily be used for development and testing purposes. A productive system, on the other hand, has to be configured carefully. If the DevelopmentMode is activated, several settings that make the developer's life easier are enabled. Unfortunately, they also make the system more insecure. For productive systems, the DevelopmentMode has to be set to false.

In detail, the DevelopmentMode activates the following: Error messages contain a lot of details, including version information and a full stack trace. The version information of many components – including the operating system – is also passed to the client. This security gap can enable targeted attacks on a computer. In ProductionMode  only an ID is shown that allows you to find the details in the log.

Responses to the browser contain internal details, such as the version information.

The possibility to acquire even more detailed internal information at any time using specific URL parameters and the Technical Info dialog box which can be accessed through the context menu.

It is essential that you deactivate the DevelopmentMode in productive systems!

The system status (DevelopmentMode on/off) is determined as follows: The system type, which is configured in the licensing service of the SAP NetWeaver Application Server, is read. If this type is not UNDEFINED, this setting is the valid one. If the system type isUNDEFINED, the Web Dynpro DevelopmentMode parameter from the default.properties file is the valid one. This means that the parameter serves as a fallback for the system type parameter.

Furthermore, the Java stack trace displays the relative path to the context data (“Cannot find file …“). We therefore recommend that you also set the DevelopmentMode parameter to False if you want to avoid the path being displayed during the error search. Then, when the error page is displayed, no stack trace is rendered: instead, the system displays the generic message “Error occurred”. Furthermore, the Java stack trace displays the relative path to the context data (“Cannot find file …“).

More information on how to set the parameter Configuring the Web Dynpro Runtime Environment

Web Dynpro Console

If the Web Dynpro configuration parameter DevelopmentMode is set to False, all version information – for example, on the Web Dynpro runtime, Java Development Kit (JDK), or client – can still be accessed by the administrator using Web Dynpro console commands. The administrator can use these commands to make the version information accessible for other users. This information includes the server operating system or the Java version, both of which are written to the HTML output for every request, accessible to other users. These users can then also access this information through the Web Dynpro Console.

Authentication

For a logical Web Dynpro application unit, which is required for starting the actual application, you can define whether or not you want to perform an authentication check. This authentication setting is part of the application configuration. You set the relevant flag when creating the application entity Application in the Web Dynpro perspective of the Developer Studio. You can use the User Management Service to check the authorizations. Various interfaces and methods are available for this purpose.

Model Import

Business API Back End

When you import an adaptive RFC model, all the security settings apply that are generally valid for the Business APIs called using RFC. Note the following security aspects regarding an RFC call: Setting up a local or central SAP System Landscape Directory (SLD) is part of the standard administration of an SAP system. If you are developing Web Dynpro applications that connect to a back end with a static user, using an SLD means that you can, for example, do without passwords as part of the Web Dynpro application code, since the SLD uses secure storage for the password. You configure an SLD for a Web Dynpro application using the administration infrastructure. The logical destination specifications are entered in the relevant wizard when importing an Adaptive RFC model. You can provide special destination specifications in the Web Dynpro Content Administrator. The connection to the destination itself is implemented in the custom controller source code.

Web Service Back End

For information about Web services and the security aspects of using them refer to the documentation for the corresponding Web service.

View Context Data

The data held and processed in the view context is a central part of every Web Dynpro application. The user interface elements, which were defined for the relevant view using the View Designer, are 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 contained in the view context in unbound form. This can be the case if, for example, data from existing SAP back-end systems is used, but it is unclear at the time of data binding which attributes are absolutely required for the Web Dynpro application. More than one Java proxy, which corresponds to a conventional Java class, is generated for each back-end Business API. Sometimes, however, not all generated proxies or model classes are required for the application. The Web Dynpro developer usually wants to define a controller context that also includes optional elements in the context-to-model binding. In a subsequent step, these optional elements are then included in the context mapping - for example, between the view context and the custom context - to make all optional data available temporarily. If not all elements of the context structure bound to the model are used for data binding, we recommend that the unused context attributes are made sufficiently secure so that they are not accidentally sent from the client to the server.

To ensure this security, you can either set the attribute property to readOnly = true in the Properties view, or delete the relevant attributes. Otherwise, unauthorized access to the view context contents using the client would be possible. The general recommendation is that the view context must not contain data that cannot be changed.

Front-End

The Web Dynpro rendering framework also contains JavaScript on the client side, and contains numerous enhancements that are specific to Web Dynpro and also help to ensure a higher level of security for the entire application. Regarding the communication protocol and integration of files from third parties for data output, you should note the following:

●      HTTPS

○       To ensure that Web Dynpro applications run securely in the browser, we recommend that you use the communication protocol Secure HTTP (HTTPS). In order to use HTTPS for Web Dynpro, you need to set the relevant flag in the administration tool. The application can then run on the port entered for the HTTPS connection.

●      Office Integration and Adobe Forms

○       If you use Microsoft Office documents or Adobe forms for the output, we recommend for security reasons, that you only use documents with signatures. Information about signature technology is available on the homepages of the providing companies. Security-relevant settings for user management and SSL connections are included in the Interactive Forms Security Guide. The Adobe Document Services Configuration Guide describes the configuration steps for setting up the users and required communication connections for the installation and configuration of the certificates for SSL connections, signatures, and certification.

Modifiable User Interface Elements

To avoid negative impact on Web Dynpro application security, we recommend that UI element parameter modification by end users, especially for width and height, is allowed in exceptional cases only - for example for a personalization feature.

If you do allow this modification, validation implementation by application developers is mandatory.

Security issues could arise, for example when values containing unwanted JavaScript commands are set dynamically at runtime. These commands would be executed whenever the interface element is displayed in the browser. This is especially important if the width or height attributes are bound to the context, since no unchecked data should be allowed to get into the context.

URL Generation Service

During the generation process, the generation service checks the URL for invalid JavaScript tags or unknown, non-predefined protocols. The administrator can configure the list of valid protocols in advance using the parameter sap.url.protocols of the default.properties file. By default, the generation service supports the protocols HTTP, HTTPS, and FTP.

URL Parameters

A Web Dynpro application can be modeled in two different ways: The application developer can either divide a complex application into several small applications that can call one another, or the application, which has varying logic, can be split into Web Dynpro components according to flow-relevant aspects and programmed accordingly. In the first case, the developer must ensure that any navigation to an application using a second calling application must always proceed with correct, valid, and non-security-relevant – that is, visible – parameters.

Theoretically, it would also be possible to address the application in any way – that is, you could pass an invalid value with the URL parameter. To prevent this unauthorized passing of URL parameters to the Web Dynpro application, you must check the validity of the parameters and specify the validity for the running application. We recommend that you do not use security-relevant parameters in the URL. This means that the Web Dynpro application developers must define the used parameters themselves and assign the valid values to the application. Therefore, the application logic in the event handler for the startup plug of an interface view addressed using a URL should be programmed in such a way that any unauthorized requests are caught and that, for example, the value is not stored in the context and the validity is checked.

Since parameters can be set using the specified URL of the Web Dynpro application, integrating a Web Dynpro application in the SAP NetWeaver Portal will result in a higher level of security for the entire application, since there is no direct access to the URL from within the SAP NetWeaver Portal.

Passwords

Should a password prompt occur when the server is being accessed, the information bound to the view context is transported to the server and back - if the same view is displayed again. The password input field, which is bound to a context attribute of the type String, is displayed in unreadable form. However, it is readable when sent to the server during data exchange with the SAP NetWeaver Application Server.

To prevent unauthorized identification of the password, the Web Dynpro application developer should transfer the password to a second context attribute that is not involved in the data flow between the view and the server. Another option is to make the field unreadable by setting it to ⁽****⁾.

Note that the password may also be displayed in readable form when tracing is executed, depending on the tracing settings. The password is only visible to the developer who used it for access.

Web Dynpro Applications in the SAP NetWeaver Portal

The SAP NetWeaver technology platform enables standardized access to user information. Roles and authorizations used for the SAP NetWeaver Portal are automatically available to Web Dynpro applications embedded as iViews. The Web Dynpro application and the SAP NetWeaver Portal can use the same user store. To access the user data, the Java API of the User Management Engine (UME) can connect to an LDAP directory, an external database, or SAP user management. The logon method Single Sign-On is available for Web Dynpro applications integrated in the SAP NetWeaver Portal. If the Web Dynpro application integrated in the SAP NetWeaver Portal accesses several back ends – that is, uses multiple back end support. Pay attention to the following security aspects of logical systems.

Logical Systems

There are a number of measures that you can take in order to ensure extra security when using logical systems in a Web Dynpro application. Since several back end systems are used through the URL parameters, it is important that you observe the following recommendations when mapping logical systems. By doing this, you can prevent unauthorized access to your logical systems through unwanted setting of URL parameters by users.

●      Logical system name

○       Check if the logical system name for the binding of application data points to the same system as the logical system name that represents the metadata.

●      Mapping settings

○       The mapping settings cannot be changed while the Web Dynpro application is running, since there can be no multiple access to different back-end systems within one application instance.

●      Naming conventions

○       Note the naming conventions for new logical systems.

●      Default connection name

○       To ensure the security of a metadata binding connection, defining a default connection whose name is at least four characters longer than the name of the application connection is recommended. This is possible if both names have the same prefix.