|
|
SAS/IntrNet 8.2: Application Dispatcher |
|
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 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 browser and the Web server.
As a security precaution, you should protect your 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 you define in the file, such as DebugMask and Debug.
Usually the configuration file is stored in the CGI executable directory along with the 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 if your Web server allows you to download a copy of the configuration file:
http://yourserver/cgi-bin/broker.cfghttp://yourserver/scripts/broker.cfghttp://yourserver/sasweb/htbin/broker.configIf you are able to download the file, then you need to adjust your Web server configuration to prevent this. Next, make sure 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 make sure that this debug flag is disabled:
http://yourserver/cgi-bin/broker?_debug=4http://yourserver/scripts/broker.exe?_debug=4 http://yourserver/sasweb/htbin/broker.cgi?_debug=4The username and password parameters in the 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 username/password, send the values to the 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.
Note: When you use the Application Broker to encrypt a username or password, the original unencrypted username and password may be saved in the Web server log. You can run the Application Broker from the command line to avoid this issue:
broker "_service=default&_debug=1&_username=myname&_password=xyzzy"
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 Broker. This requires that users supply a userid and password in their Web browser to run the Broker. When a Web server launches a CGI program that is authenticated, it supplies the userid 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 may be easy for users to fake the value of the REMOTE_USER variable without authenticating. Because the 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 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 section titled Application Server Should Not Trust the Broker for an explanation of how to overcome this problem.
|
|
SAS/IntrNet 8.2: Application Dispatcher |
|