Writing Web Applications With WAI: Netscape Enterprise Server/FastTrack Server, Version 3.0/3.01

Chapter 8
Security Guidelines for Using WAI

Using WAI, you can write and compile an application that runs as its own process (outside the web server's process). When a client accesses your web service, the web server uses a built-in name service to find your application process and execute the Run method (or, in C programs, the corresponding C function of the type WAIRunFunction) in your web service application class.

This section discusses some of the potential security concerns that may arise from the way in which the web server finds your application process. Before you enable WAI on your server, make sure to read this chapter thoroughly.

How the Server Finds Your Application

When you start up your WAI application for the first time, your application registers with the web server's built-in name service. The web server saves the information with the name service.

In order to access your service, end users enter a URL (or click on a link) that contains the name of your service. When this URL is requested, the web server uses its built-in name service to find the registered WAI application with the same name. The server then invokes the Run method in your web application service class.

For example, when you start the WASP example (which is provided with the web server) for the first time, the example registers itself to the web server with the name WASP (for the C++ example) or JavaWASP (for the Java example). End users can access the service through the URL http://hostname:port/iiop/WASP (or JavaWASP).

By default, the basic object adapter (BOA) in the web server is set to listen only to the local host (the loopback address, 127.0.0.1), not to a network IP address. This configuration assumes that you plan to run your web application services on the same machine as your web server.

Although it is possible to enable the web server's BOA to accept requests from remote machines, you should be aware of the potential security issues surrounding this configuration before choosing to set up your web server in this way. The rest of this chapter explains these potential security concerns.

Potential Security Concerns

When running WAI applications with your web server, the following scenarios could occur:

Someone could replace a web service by running another program that registers under the same name. Potentially, a user could write a program that registers itself under the same name as an existing web service. If the original application that provides the service stops running (for example, if it crashes), another application registered under the same name can take its place.

For example, suppose you are running the WASP example. Someone else could write a program that registered itself under the same name (WASP) and run the program on the web server's host machine. If the original WASP application terminates, the web server's name service will find the other service registered as WASP, and the web server will use that service.

Someone could replace a web service or add a new service by uploading a file to the server. A user with permission to the directory containing your plug-ins or programs could conceivably overwrite those files. For example, if you are running the WASP example, someone else could write a program with the same filename (WASP) and copy that file over your original file.

Someone could run a program on a separate machine and register the program with your web server. If you configure your web server to allow IIOP connections from other machines, programs running on other machines can register with your web server.

(Note that by default, your web server is configured to listen for IIOP connections from only the local host address 127.0.0.1.)

The following figure illustrates the potential security concerns with enabling the web server to run WAI applications.

Recommended Guidelines

In order to reduce the possibility that security problems might occur, Netscape recommends that you follow these guidelines:

Restrict login access to the web server's host machine. If possible, do not allow guest logins to the machine. Anyone with the ability to execute a program has the potential to register it as a WAI service to your web server.

Make sure that write permissions are adequately set on web server's host machine. Verify that write permissions are restricted to directories and files on the web server. In particular, make sure that server plug-ins loaded by the server or programs started automatically by your machine are write-protected.

Run WAI applications on the local machine only (the machine on which the web server runs). Although you can set up the web server to access WAI applications running on other machines, configuring the server this way increases the risk of potential security problems. Anyone with the ability to run a program on any machine will have the potential to register the program as a WAI service.

(For 3.0 servers only) Restrict osagent so that it only accepts connections from the local host. Although the web server primarily uses its built-in name service to register WAI applications, osagent can also register WAI applications if the name service is down.

To configure osagent to accept connections only from the local host machine, specify the -a option with the argument 127.0.0.1 (localhost):

   osagent -a 127.0.0.1

The following figure illustrates the recommended guidelines for dealing potential security concerns.

Enabling IIOP Connections from Other Machines

Although Netscape recommends running WAI applications only on the web server's host machine, it is possible to run WAI applications on other machines and have CORBA object implementations on other machines interact with the web servers.

Configuring Your Web Server

To enable the web server to register and find WAI applications running on other machines, you need to configure the web server to use its network IP address instead of the localhost IP address (127.0.0.1).

In the obj.conf file for your server, find the Init directive that calls the IIOPinit function. Use the OAipaddr parameter to specify the IP address that the BOA uses. For example, if you want the BOA set up to use the IP address 204.200.215.98 instead of the local hosr, use the following syntax:

   Init LateInit="yes" fn="IIOPinit" OAipaddr="204.200.215.98"

For more information, see "Configuring the Web Server's ORB".

(3.0 only) Running osagent

If you are not restricting the ORB to the local host machine only, you do not need to specify the -a flag when running the osagent utility.

This flag restricts osagent to finding WAI applications on the local host machine only. Without this flag specified, osagent will be able to find applications running on any machine in your local network.

[Contents] [Previous] [Next] [Index]

Last Updated: 12/04/97 16:12:44

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use

Chapter 8 Security Guidelines for Using WAI

How the Server Finds Your Application

Potential Security Concerns

Recommended Guidelines

Enabling IIOP Connections from Other Machines

Configuring Your Web Server

(3.0 only) Running osagent

Chapter 8
Security Guidelines for Using WAI