Contents SAS/IntrNet 1.2: Application Dispatcher Previous Next
 

Security

As you begin to work with the Application Dispatcher, you can enhance the security of your applications using the following tips:

Use a secure Web server

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 with 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 they pass through the various computers between browser and server.

Use Web server password authentication

Both secure and nonsecure Web servers can prompt users for their username and password, referred to as authenticating the user. You can set up your Web server so that the Broker CGI requires users to authenticate themselves. Successful authentication causes the Web server to set the environment variable REMOTE_USER to the username entered in the browser authentication dialog window. Depending on your configuration file settings, the Broker passes REMOTE_USER with a name of _RMTUSER to the Application Server, which makes the name available to your Dispatcher program.

If your Dispatcher program requires additional security, it can check the value against an observation in a security data set (created by the developer of the Dispatcher program) to determine whether this authenticated user is allowed to use the application. Additionally, you can use REMOTE_ADDR to check for access privileges based on the client's IP number.

Restrict access to Application Server control files

The server control files srvauto.sas, permdata.sas, and reset.sas could pose potential security gaps. To maintain security, you should restrict access to these files. You can restrict access to the server root directory containing these files, restrict access to the files themselves, or both. If you allow unlimited access to the srvauto.sas file, anyone could define a new application library and execute any Dispatcher program. All three control files contain SAS code that is executed sometime during the life of the server. You should secure all three files.

Restrict access to application libraries

Do not permit unlimited access to existing application libraries. To achieve a high security level, restrict access to the Dispatcher application libraries only to those developers who should copy applications into these areas.

Review new or modified code for security risks

To prevent security holes that could be created inadvertently, review any new code or code that has been changed in any way. Look for potential problems described on this page.

Avoid using the ampersand reference to macro variables

SAS macro variables contain the data used by Dispatcher programs. Unfortunately, the simplest way to extract this information is the most insecure. If possible, avoid using the ampersand reference to a macro variable, such as

color = "&color";

If your application has restricted access so that only a small set of trusted individuals use it, you may be able to ignore this precaution. However, to be on the safe side, you should always attempt to write secure code.

In general, data contained in these macro variables can be categorized two ways:

  • pure data intended for recording, querying, or analyzing
  • code data intended to dynamically create variable names, code statements, or conditional logic.

In the case of pure data, values are almost always transferred immediately from macro variables to DATA step variables. The following sample illustrates two ways you could do this:

color = "&color";
color = symget('color');

Although these two statements produce equivalent results, the latter is much safer than the former. Using symget prevents the SAS code parsing mechanism from seeing the contents of the macro variable. If the macro variable color were to contain valid SAS code, a reference to &color would resolve and the code contained within it might execute. This is very dangerous because the client has passed this data. If you want to treat the macro variable value as pure data, you do not need to use the ampersand reference.

However, you may want to use the value of a macro variable to dynamically create variable names, code statements, or conditional logic. In these situations, take extra care in evaluating your program for security gaps.

You could scan macro variable values for unwanted characters and refuse to create and execute the dynamic code if such characters exist. Alternatively, and even safer, you could check the value of a macro variable against a list of valid values before actually using it.

Either way, to prevent unwanted macro resolution of embedded code, we suggest using the %SUPERQ function rather than an ampersand reference. For example, suppose you had a simple program that printed the contents of a data set given its name. You might be tempted to write your program like the following example:

proc print data=&dsname;
run;

However, it is safer to do the following:

proc print data=%superq(dsname);
run;

And even safer to do the following: 

%macro checkit;
  %if %upcase(%superq(dsname))=SASUSER.CRIME or
      %upcase(%superq(dsname))=SASUSER.ORANGES %then %do;
    proc print data=%superq(dsname);
    run;
  %end;
  %else %do;
    /*print an error message*/
  %end;
%mend checkit;
%checkit

Use password protected data sets

As an added level of security, you can protect access to your data by using password-protected data sets. This feature of SAS software lets you assign a password to a data set and then requires you to supply the password to access or modify the data set. You can choose to code the password to the data set in your application or require the user to supply it. If you code the password into your application, ensure that the user cannot view that password by returning the SAS log to the browser. To prevent this, see the following sections describing the use of SCL or OPTIONS NOSOURCE.

Use SCL or compiled macro code

One feature of the Application Dispatcher lets you view the SAS log. This helps when developing an application; however, it creates a potential security risk in a production level application. Programs of type .SAS, .SOURCE, and .MACRO all submit statements that appear in the log. SCL (SAS Screen Control Language available with SAS/AF software) statements do not appear in the log.

You can accomplish many of the same tasks in SCL that you can by using these other program types. SCL is the most secure program type. If you create your Dispatcher program with SCL and the user attempts to return the SAS log, your program statements do not appear. Additionally, SCL is more secure because it is a compiled language. Compiled macros (.MACRO program types) share this feature. Using SCL lets you compile the program and actually delete the readable source, preventing someone from reading the program statements even if they gained access to the SAS catalog on the Application Server machine.

Note that running the .MACRO entry prints the original source to the SAS log if the MPRINT option is set. To prevent this, you can include the following statement in your server reset.sas file:

OPTIONS NOMPRINT;

For information on other ways to protect your source, see the following section that describes OPTIONS NOSOURCE.

Use OPTIONS NOSOURCE

A global option controls printing of the program source to the SAS log. By placing 

OPTIONS NOSOURCE;

in the server reset.sas file, you can instruct SAS software not to echo each submitted line to the SAS log. If you only need to protect the source from appearing for individual programs, you can include an OPTIONS NOSOURCE; statement at the beginning of those programs. Unfortunately, this will make debugging programs more difficult.

Use the DebugMask and ServiceDebugMask directives

The Application Dispatcher has several debugging options that can be turned on and off through the _DEBUG field in Dispatcher requests. Some of these options might represent security risks including a few that are not documented and are used by Technical Support. For example, the Dispatcher includes an option to show the SAS log (which might contain source code), the host name and port number where the Application Server is running, or a list of all services known to the Broker. To create a secure Dispatcher setup, decide which debugging options you want to allow and set the value of DebugMask or ServiceDebugMask in the Broker configuration file to the sum of those options. For example, if you want to allow only the field echo (1), status message (2), and output dump (16) values, you would set DebugMask to 19 (1+2+16). Remember, by default all debugging options are allowed.

Use POST method

One simple, but not iron-clad, security technique is to use the POST method when you invoke the Broker. In your HTML form tag, you specify ACTION=, which points to the Broker. In addition, you can specify a method as shown in the following example:

<FORM ACTION="/cgi-bin/broker" METHOD="POST">

The POST method passes all form variables to the Broker on standard input, which prevents them from appearing as part of the URL. This makes it more difficult for users to subvert the values sent to your program. Using POST also prevents the submitted form data from appearing in the Web server log files. However, using POST prevents your users from bookmarking those dynamically generated pages.
Contents SAS/IntrNet 1.2: Application Dispatcher Previous Next