S 5.69 Protection against active content

Initiation responsibility: Head of IT Section, IT Security Management

Implementation responsibility: IT Security Management, Administrators

Until recently, firewalls were considered to provide absolute protection against attacks on one's own network from the Internet. They ensured that no connection could be set up into the internal network from the Internet, and that internal users could access information on the Internet without difficulty. On account of the ever more widespread distribution of active content on WWW pages, however, this situation has changed. Information from the Internet is no longer simply viewed, but instead in some cases external program code is also executed during viewing. At present this means Java, ActiveX and JavaScript; others could be added to this list in future. There are also elements known as plug-ins which enable other programs to be started from the browser; in some cases this is even done automatically from a HTML page. Depending on the type of program involved, executing it may be associated with a certain security risk.

From today's standpoint there are several conceivable approaches to protecting an internal network against misuse by active content from the Internet. These are explained in the following using the examples of Java, ActiveX and JavaScript.

Prohibition of active content on the firewall

Even today it is still possible to have very good access to the Internet without really needing active content. This is the safest and therefore recommended method of accessing the Internet, because in that way the firewall can continue to exercise principal control. In order to prevent the acceptance of active content, it is necessary to have a proxy on the application gateway, which examines HTML pages for active content. If the proxy finds any such content, it must be filtered out of the page. There are a number of application gateways that offer this functionality (see S 2.75 Selection of a suitable application gateway).

It must be assumed, however, that this solution, although it is the safest, will be less and less acceptable in the future, because the number of pages where the active content contains the actual information is on the increase. If the active content is filtered out, the internal user will no longer be able to access the information.

Note: Active content may also be hidden in e-mails; these should therefore also be examined for such content. As encrypted communications cannot be checked for active content, SSL-based WWW access must not be allowed if there is central filtering.

Prohibition of active content in the WWW browser

In a network with centrally administered workstations, it is conceivable to restrict the rights of the individual users to the extent that they are no longer able to change the security settings of their WWW browsers. These can then be configured in such a way that active content will not be executed. It is thus also possible to dispense with the filtering of active content on the application gateway, because in these circumstances active content can no longer cause any harm in the internal network.

Another solution is to allow only certain WWW browsers to be used for access to the Internet. Netscape Communicator and Internet Explorer are not the only browsers available; there are also other browsers that have no means of executing active content.

One option is to ensure that browsers of this type will be used by setting up the administration of the workstations to this effect. In this case, however, the operating systems of the workstation must provide reliable separation of roles between users and administrators, such that configurations set by the administrator cannot be revoked by a user. Additional security precautions are therefore necessary with operating systems such as Windows 3.1 and Windows 95.

Alternatively, the proxy on the firewall could be set up in such a way that only predefined browser software is allowed access to the Internet. It must be borne in mind in this case, however, that the security of this method is dependent on the ID of the WWW browser used. A skilled user with a hex editor should have no difficulty modifying a WWW browser of his choice in such a way that it has the desired ID.

Raising the awareness of users

It is also conceivable to place the responsibility entirely in the hands of the users. Active content should normally be deactivated in the WWW browser, but the users have permission to run active content in certain circumstances. This could be the case for example if they were no longer able to access the WWW information provided by a well-known manufacturer without running the active content.

ActiveX, in particular, has various security settings, which enable the execution of ActiveX to be restricted to certain WWW servers so that users are not forced to change their settings repeatedly.

There must be some doubt, however, whether users will really always change the security settings of their WWW browsers when they switch to another WWW page, for example where a link from the "well-known manufacturer" may have taken them. Besides, an individual Web page on a "secure" computer can also load other Web pages which are located on "non-secure" computers. As well as that, attacks can be made on the Internet which have the effect that users do not receive the WWW page that they requested (see T 5.48 IP spoofing and T 5.78 DNS spoofing, for example).

Filtering specific active content

Recently programs have been developed which work in a similar way to computer virus scanning programs by examining active content to determine whether it contains code that is a threat to security. This is a highly acceptable solution for users, because they can then access all harmless active content.

The question has to be asked, though, whether such programs really provide protection. A virus scanning program cannot provide protection against Trojan horses, for example, and these can of course cause considerable damage.

Running active content in a protected environment

Java and JavaScript are implemented in WWW browsers in such a way that they are executed in what is known as a sandbox. If the sandbox is correctly implemented, the active content cannot access data outside the sandbox. Although attacks on availability (denial-of-service (DOS) attacks) are still possible, the confidentiality and integrity or other data is not endangered. The sandbox technique cannot be further extended.

Two approaches suggest themselves here:

1. On an operating system with role separation, the WWW browser can run under a user ID with minimal rights. Active content can therefore not cause any damage, provided the checking of rights operates correctly.

On a Unix computer it is possible, for example, to launch a WWW browser in a change-root environment, in which the WWW browser only has access to a restricted file system. If active content does cause damage, it can only do so within this restricted environment. To enable a user to work from his workstation, the WWW browser must be displayed on it; this would be possible with X-Windows, for example. A similar setup is possible with Windows NT.

2. Recently proxies have been developed (see www.digitivity.com for example) which take over the running of Java applets instead of the workstation; this means that the Java applet is run on the proxy but displayed on the workstation. Compared with the first method, this approach makes much more careful use of the available network bandwidth.

Recommendation:

1. Active content in the form of ActiveX should only be executed (if at all) when it comes from a trustworthy source, i.e. when it has been signed, the signature has been verified and the signer is also trustworthy.

2. Java and JavaScript should only be allowed (if at all) when they come from a trustworthy source, or alternatively when the above safeguards have been verifiably implemented.

3. It is recommended not only to have active content encapsulated by the WWW browsers but also to ensure that it is additionally restricted by a suitable operating system.