S 4.404 Secure design of the logic of web applications

Initiation responsibility: Specialised Department, IT Security Officer, Persons responsible for individual applications

Implementation responsibility: Developer, Tester

Web applications image complex business processes which go beyond merely displaying individual websites. When technically designing these processes, it must be ensured that the implemented application logic cannot be misused. For example, it must not be possible to exit the designed process of the web application and control the course of the process from the outside.

The requirements for the imaged business logic must be captured exactly and implemented properly so that only intended and designed actions can be performed. Any deviating behaviour must be rejected. For example, if a recommendation feature of the web application is exclusively designed for sending item recommendations, it should be taken into consideration that this feature may also be misused to send spam emails. If the recommendation text is not specified in this example, this feature may be used to send spam. Furthermore, it must additionally be checked whether errors in the business logic caused by two concurrent sessions may occur (race conditions).

Therefore, all features should be documented on the basis of use cases when designing the web application. In so doing, the purpose the features are to be used for and how any misuse may be avoided should be recorded.

If the web application is cancelled due to any reason, the logic must ensure that the web application is returned to a consistent condition (roll back).

Interactive features in web offers may also be implemented by active content executed on the client system (e.g. via JavaScript). It is often also possible to provide these features by means of dynamic or static content. Since the use of active content on client systems often is disabled due to security reasons, it is recommendable to refrain from using active content and to implement the application logic only on the server when designing the web application.

Interactive features in web applications can be implemented differently: on the server or on the client. Since the client is not controlled by the web application, it cannot be ruled out that the client is misused. Especially active content such as JavaScript or ActiveX was and is frequently used to attack web applications and the information they manage. From a security perspective, it is therefore recommendable to implement active content on the server or, where possible, to refrain from using active content.

If using active content is required, the following items must be observed:

• It should be ensured that the web application can also be used even if the execution of active content is disabled in the browser.
• If possible, it should be comprehensible which source active content was taken from in order to be able to perform an effective check in the client. This may be accomplished by signing ActiveX components, for example.
• If serialising and dynamically creating XML data cannot be avoided when using Ajax, Frameworks should be relied upon, where possible.
• When using JavaScript, the eval() function should not be called.
• If the web application uses JSON for data exchange, only objects must be used as top-level elements.

Examples:

• A web application authenticates the users in several, successive steps. In the first step, the users must enter their user name and password, and in the second step, they must enter an authentication token. In this case, it should not be possible to skip the first step in order to ensure that all authentication features are entered. In the last step, all authentication features must again be checked for final authentication.
• During the design phase of a banking application, it must already be considered that a user can also enter negative amounts into a bank transfer form. In this, the web application must ensure that the logic of the bank transfer form is not inverted and that no unscheduled credit is triggered by the aforementioned.

Review questions:

• Are use cases documented for the features of the web application?
• Do the documented use cases of the web application take into consideration any misuse of the features?
• Was there an assessment as to whether the use of active content can be refrained from for web applications?
• Was the use of active content limited to the necessary extent?