S 4.127 Secure configuration of browser access to Lotus Notes

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: Administrator

To access a Lotus Domino server via the Web interface, the user needs a "Web client" in the form of a browser. Access to the server data involves querying the HTTP module of Domino Server. This extracts the data from the relevant databases and converts it to WWW pages so that they can be displayed by the user's browser. Through the use of active content (JavaScript, Java applets) it is possible for the database content to be modified via a graphical user interface that emulates the normal Notes client.

Security during Web access depends on the security of the components involved. As well as the secure configuration of the server (see S 4.122 Configuration for browser access to Lotus Notes) and active protection of communications (see S 5.86 Use of encryption procedures with browser access to Lotus Notes), the security of the Web client is also an important factor.

During Web access, the confidential authentication information is stored on the client. If an unauthorised third party gains access to this data, then he can access the databases on a server using the authorisations of the compromised user. The authentication data requiring protection in this context is as follows:

• User name and password for Web access. This data should not be stored locally as the security of authentication depends on this data being exclusively known to the user in question, who has to re-enter the information every time authentication is required. Unfortunately modern browsers often allow this data to be stored locally so that on subsequent accesses to the similarly stored address of the server it is automatically transmitted to the server. Users must therefore be told that the password for Web access must not be stored locally.

• Cryptographic keys and certificates which are used during SSL client authentication. As this authentication data is only available in machine-readable form, it is necessary for the data to be stored. Generally the data is stored locally on the client.

In general a distinction can be made between the physical security of the computer which serves as client and the security of the browser used as Web client. This gives rise to the security aspects described below.

Local storage of the authentication data makes physical security especially important. Therefore modules in Chapter 5 that are relevant to the security of the client should be carefully implemented.

In particular the following measures where applicable should be applied to the computers used:

• S 4.1 Password protection for IT systems

• S 1.33 Safe keeping of laptop PCs during mobile use

• S 1.34 Safe keeping of laptop PCs during stationary use

• S. 144 Suitable configuration of a home workplace

• S 1.46 Use of anti-theft devices

In addition the security of the browser must also be considered. This applies especially where authentication data is stored locally by the browser. The issues requiring consideration include the following:

• Where will the authentication data be stored?

Possible storage locations include, for example, a file, a database, the Registry, a smart card or the system certificate store (under Windows 2000).

• Is the authentication data stored protected?

Possible protection mechanisms include encryption, password protection or a PIN-protected hardware token (or possibly a smart card).

• How strong is the protection afforded by the security mechanisms used?

With encryption, the strength of the protection is essentially determined by the procedures used and the key lengths employed.

If authentication data is stored locally on the client, this data should be protected so that access cannot be gained to it even after the computer or the protection mechanisms of the operating system has/have been physically compromised. This normally requires the use of encryption mechanisms within the browser. If these requirements are not satisfied by the browser, then a risk assessment must be carried out and a decision made as to whether Web access should still be allowed. This will depend ultimately also on what data is to be accessed.

Another problem area is the use of active content during Web access. In order that the functionality of the Web interface can be used to the full, it is necessary that processing and execution of active content are enabled in the browser used, as the HTML pages generated by Domino Server contain JavaScript and Java applets. If the relevant support is disabled in the browser, then virtually a complete loss of functionality must be accepted.

If, however, the browser is also used to access the Internet, then generally the execution of active content must be disabled (see S 5.69 Protection against active content). If the adjustment is made by the user himself, then it is easy with mixed use of the browser to forget to disable active content for Internet access. This then implies an increased danger to the local computer network, as it is now possible for harmful active content to be executed by the browser. Mixed use of the browser should therefore be avoided if possible.

Incorrect use of browsers by users can result in a number of security problems. Therefore users must be instructed as to how to use browsers securely and obliged to observe the security guidelines that are in force.