Application Broker and Web Server Security

One security risk involves the network between the Web browser and the Web server. You can improve security by using a secure Web server. A secure Web server uses an HTTPS protocol, which is HTTP that has secure sockets. This protocol encrypts all the data flowing back-and-forth between the Web browser and the Web server. Unauthorized users are not able to decipher the secure packets of data as it passes through the various computers between the Web browser and the Web server.

Parameters on a GET request are logged by the Web server. This means that passwords and other sensitive parameters might be captured in the Web server log. Using POST generally prevents submitted form data from appearing in the Web server log files. You should use POST instead of GET to handle sensitive data in Application Dispatcher requests, although POST is not a guarantee that the Web server will not log input parameters.

As a security precaution, you should protect your Application Broker configuration file. Your first priority should be to restrict file system access so that only specific individuals can update the configuration file. Protecting this file means that you can rely on the settings that you define in the file, such as DebugMask and Debug.

Usually the configuration file is stored in the CGI executable directory along with the Application Broker executable. Some Web servers allow files stored in a CGI executable directory to be downloaded the same way as a regular HTML file. To test this, try one of the following URLs, and see whether your Web server allows you to download a copy of the configuration file:

If you are able to download the file, then you need to adjust your Web server configuration to prevent this. Next, ensure that the DebugMask value is set in your configuration file to disallow _DEBUG=4. This debug value displays the contents of the configuration file. Try one of the following URLs, to ensure that this debug flag is disabled:

The user name and password parameters in the Application Broker configuration file can be encrypted or entered as open text. If a value starts with an exclamation point (!), the value is assumed to be encrypted. To obtain the encrypted equivalent for a user name and password, send the values to the Application Broker with a _DEBUG=1. For example,

http://abc.def.com/cgi-bin/broker?
_service=default&_debug=1&_username=myname&_password=xyzzy

should produce output with the fields encrypted following an exclamation point (!). These new values can then be used in place of the original open-text versions.

broker "_service=default&_debug=1&_username=myname&_password=xyzzy"

An alternative to entering this password in plain-text is to use the encrypted version of the password. For example, if your password is xyzzy, the encrypted version that you can put into the broker.cfg is !ci3mC.Xmq.t2Chnx. By hardcoding the encrypted version in the broker.cfg, the text of your actual password is protected from anyone who has read access to the broker.cfg file.

By default, Web servers enable any client to connect and make an anonymous request for a static page or a CGI program. You can enable Web server authentication for the CGI executable directory that contains the Application Broker. This requires that users supply a user ID and password in their Web browser to run the Application Broker. When a Web server launches a CGI program that is authenticated, it supplies the user ID of the client in the environment variable REMOTE_USER. By examining the corresponding SAS macro variable, _RMTUSER, your programs can determine who the requesting client is. Using this information, you can provide the appropriate access to application features.

Note that it might be easy for users to fake the value of the REMOTE_USER variable without authenticating. Because the Application Broker program accepts this value through an environment variable, users can set the environment variable REMOTE_USER to any value that they want and run the Application Broker from an operating system command prompt. Therefore, they can masquerade as other users and the Application Server does not know the difference. See The Application Server Should Not Trust the Application Broker for an explanation of how to overcome this problem.