Security Aspects of Web Dynpro for Java

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 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, set the DevelopmentMode to false.

In detail, the DevelopmentMode activates the following: Error messages contain numerous 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.

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 isn't UNDEFINED , this setting is the valid one. If the system type is UNDEFINED , 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 …). To avoid the path being displayed during the error search, we recommend that you also set the DevelopmentMode parameter to False. 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

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're 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.

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's 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's unclear at the time of data binding which attributes are 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 aren't 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 can't 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). To use HTTPS for Web Dynpro, enter the values appropriate in the administration tool. For more information about parameter sap.url.protocols and how to make changes to it, see Configuring the Web Dynpro Runtime Environment.

• 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.

In the context of JavaScript, the WebWidget user interface element should be mentioned: Security audits are recommended if Web Widgets shall be used for user interface design.

WebWidget

Any custom client-side JavaScript can cause some security concerns. The security cannot be ensured from the WebWidget implementation by default and that is why for all applications using WegWidgets security is critical.

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, nonpredefined 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 don't 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 isn't 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 Enterprise Portal results in a higher level of security for the entire application, since there's no direct access to the URL from within the SAP Enterprise Portal.

Action Events

We recommend implementing critical code, like for example when you write data into the back-end, only within an action event method, and not within another hook method like for example wdDoInit ().

The reason is that the Web Dynpro framework has security mechanism to protect against attacks. The framework internally uses request parameters for client-server communication. These parameters are protected by the framework as following:

To provide the highest security level for the Web Dynpro applications, request parameters triggering an action event are only accepted in a follow-up request but not within the first request. Note that the parameters are ignored if sent within the first request. Furthermore, the parameters are only accepted as POST parameters. Note that they are ignored if they're sent as GET parameters. Finally, the parameters are only accepted if the request contains a valid Cross-Site Request Forgery (XSRF) token prohibiting protection against such attacks. Note that an error page is shown if the token is missing.

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 Enterprise Portal

The SAP NetWeaver technology platform enables standardized access to user information. Roles and authorizations used for the SAP Enterprise Portal are automatically available to Web Dynpro applications embedded as iViews. The Web Dynpro application and the SAP Enterprise 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 Enterprise Portal. If the Web Dynpro application integrated in the SAP Enterprise 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.

Clickjacking Protection

To prevent malicious applications from using Java Web Dynpro applications for clickjacking attacks, it is necessary to protect the Java Web Dynpro applications accordingly, in particular when they contain sensitive functions. To prevent clickjacking, Web Dynpro Java framework provides the ClickjackingProtection service.

The clickjacking/check servlet determines whether SAP NetWeaver AS for Java is enabled for clickjacking framework protection. See SAP Note 2170590 to check the availability of the servlet in different releases and SPs. All frameworks, which support clickjacking framing protection, consume the clickjacking/check servlet:

https://<host>:<port>/sap.com~tc~lm~itsam~servlet~clickjacking/check

This information needs to be available for web applications, which do not require authentication, so the servlet does not require authentication either. From a security point of view, we do not consider the lack of authentication to be information disclosure, because the information returned by this servlet – whether clickjacking protection is enabled – can be checked at the client side anyway. This is true for all current clickjacking protection mechanisms used in modern web applications and recommended by OWASP. See also https://www.owasp.org/index.php/Clickjacking

The ClickjackingProtection service uses a feature of the PostMessage API to detect the origin of the framing window and compares it against a fixed value or list.

Using the ClickjackingProtection service you can prevent Java Web Dynpro applications generally from being embedded into other web applications. Additionally you can define exceptions to this general behaviour to allow web applications from certain trusted hosts to embed the Java Web Dynpro applications. These exceptions are configured within the respective whitelist.

See also Clickjacking in the Secure Programming Guide.

X-Frame-Options HTTP Header field

Also still available is the X-Frame-Options HTTP header field. This feature was introduced by Microsoft Internet Explorer 8+ and has been adopted by other browser vendors. Depending on the attribute value, the browser evaluates which hosting frames are allowed to include a certain page in a frame.

Supported values:

• DENY (no embedding allowed)
• SAMEORIGIN (only embedding frames from the same origin allowed)
• ALLOW-FROM domain.com (only embedding frames from specifically declared hosts allowed)

For more information see SAP Note 1781171 .