Security of View Context Data

Use

Exposing Data from the View Context

The data stored 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 in the View Designer are normally bound to the individual view context elements by the Web Dynpro application developer to ensure that data can flow between the client and the server.

However, view context data that is unbound can also exist in the view context, for instance, if an ABAP Dictionary structure containing further attributes that are not visible is used. A standard and secure way of protecting context attributes from being changed by clients is to set the READ_ONLY property of the context attribute info ( IF_WD_CONTEXT_NODE_INFO) to ABAP_TRUE. The settings of individual context attributes made in the context attribute properties are however not evaluated.

Removing a context attribute from the View Designer has no effect on security at all for mapped context nodes and context nodes with DDIC connection. A removed attribute will no longer be visible in the Workbench, but can still be used in dynamic programming.

The following points apply for making write access to the context secure:

  • When view context data is accessed by the client, the Web Dynpro Framework checks whether a context attribute is currently visible from a UI element. If not, a short dump results.

  • When data is exposed from the view context, the Web Dynpro Framework checks whether a context attribute exists and can be changed. If not, a short dump results.

  • With the data type check the Web Dynpro Framework checks whether the data type of the attribute is valid. If not, an error message is issued.

  • For all UI elements that have changeable values the application developer must check which changes are permitted and therefore prevent unauthorized access to the business logic.

Client Access to View Context Data

Web Dynpro HTML rendering ensures that only those context attributes can be displayed on the client and changed by the client that are actually allowed to be.

This means that:

  • Only if a context attribute is bound to a property of a UI element and the UI element is currently visible, is the value of the context attribute transported to the client.

    Example: Property TextView.text is bound to context attribute DATA.AIRLINE. If the UI element is visible, the value is read from attribute DATA.AIRLINE and sent to the client as TextView Text.

  • Only if a context attribute is bound to a property of a UI element, the UI element is currently visible, and the current setting allows for the value to be changed, can the value of a context attribute be changed.

    Example: Property TextView.text is bound to context attribute DATA.AIRLINE. If the UI element is visible, the value is read from attribute DATA.AIRLINE and sent to the client as TextView Text. Since property text does not allow the user to make changes, the Framework prevents the attribute from being changed by the client.

    Example: Property InputField.value is bound to context attribute DATA.AMOUNT. If the UI element is visible, the value is read from attribute DATA.AMOUNT, and the value can be changed by the client. However, if property InputField.enabled is set to false, or if InputField.readOnly is set to true, the attribute cannot be changed by the client.

Data Type Check

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, and if necessary, reject the input. This includes checking specific types of attacks, such as SQL attacks if an input is used later in a dynamic SQL statement.