|
|
Security must be in focus in all parts of the web application environment. This includes configuration of firewall, web server, and network, which much be secured properly and kept up to date with security patches.
It is equally important that web application security is a point of focus during the development process.
While WebsydianExpress has many built-in features that support and handle security, the web application developer is still responsible for handling security in some cases.
This document describes where the developer must focus in order to keep the web application secure and robust.
In a web application environment the same server job can be used to handle requests from many different users (sessions). For this reason it is not possible to store values related to the session in program variables or in the TEMP library.
Instead data that is related to the session must be stored in a database file keyed by the session ID. The session ID for the current session can always be fetched using the API GetSessionID.
Please find more information in Store Session Data.
When a web application job starts the handling of a request it is therefore important that all variables are cleared before use. This ensures that no values from the last processed request are reused (which would be a problem since the last processed request could originate from another session/user).
When a web application generates an event on an HTML page it includes the input fields (if any) where the user can enter the values needed by the event. Besides that some hidden fields are also generated; they contain values needed by the program handling the event, but should not be displayed to the user.
These hidden fields are used to store the session ID, event ID, and the secure parameters.
The issue is that while these hidden fields cannot be seen in the browser, it is still relatively easy for a person to modify the values of the hidden fields by saving a copy of the displayed HTML page to the local hard disk, modify the hidden fields, and then activate the event containing the modified hidden fields.
So when using hidden fields it is important that the web application somehow can detect if the hidden fields have been modified.
WebsydianExpress uses a signature to do this. Whenever an event is generated on an HTML page WebsydianExpress automatically adds a signature based on the values of the hidden fields to the event. The signature itself is also stored in a hidden field.
The program handling an event can then recalculate the signature based on the received values and then compare the recalculated signature with the signature received from the event. If there is a mismatch then one or more of the hidden fields have been modified and further processing of the event should be aborted.
The APIs SetParm and SetGridParm are used to set secure parameters when generating an event, and the APIs GetParm and ValidateParm are used to retrieve and validate the secure parameters when processing an event.
WebsydianExpress automatically adds the session ID and the event ID as hidden fields, and validates these when an event is activated.
So it is only necessary to validate the secure parameters set by the application.
It is a security flaw if secure parameters are not validated before use.
Always remember to use ValidateParm after retrieving all the secure parameters with GetParm.
For an example on how to use secure parameters then look in the Order Catalog application.
All web input values are received as alphanumeric data. This means that before these values can be used they must be moved to a variable with the correct type before using the data.
As web input data is received from the Internet it is a security flaw to make any assumption about the validity of the data. This means that if a user is asked to enter his age, there is no guarantee whatsoever that the received value will be an integer value within the legal range. The user could have entered "4567" or even "ac#r" just to see how the web application would behave.
It is therefore important to do proper error handling when moving a received alphanumeric value to a variable with another type, and to validate all received web input data.
Always validate all web input values before use.
It is possible to insert some sort of validation in the browser page using JavaScript or setting a max length on an input field. However, it is not guaranteed that the JavaScript will work in all browsers and it is also easy for a user to disable the JavaScript in the browser, so all the validation in the web application is still required.
In most web applications there is a need to determine the identity of users (authentication). In WebsydianExpress authentication is handled by defining users in the administration interface, and assigning an authorization level to them. The authorization level then determines what the user has access to within WebsydianExpress.
The web application can then use the API GetSessionData to retrieve the ID of the user who has logged in. If the user has not logged in the user ID will be blank (anonymous user).
As mentioned above the authorization level is used to determine what the user has access to within WebsydianExpress, meaning what menu items the user is allowed to see and access.
The authorization level can also be used programmatically in the web application to determine what content should be displayed for the user.
Online documentation - WebsydianExpress v3.5