ECN No Name Newsletter: Fall, 1997

The ECN No Name Newsletter is no longer being published. This is an archived issue.

[previous article] [next article]

Security On The Web

Kyler Laird, ECN Technical Webmaster
kyler@purdue.edu

ECN has been developing tools to assist in making the Web a little more secure. This article describes our HTTP Secure Server Layer (SSL) server and a utility to make setuid scripts safer.

Secure HTTP Server

Data going between a Web client and server via HTTP is normally unencrypted and can be easily viewed by anyone with privileged access to any of the computers or networks between the client and the server. When browsing the Web for general information, this usually isn't a problem, but when users submit "private" data about themselves, it quickly becomes an issue that should be considered by the user and the maintainer of the system requesting the data.

ECN has recently been testing an HTTP server with SSL extensions which gives us the ability to accept form data through encrypted transmissions. The first application of this server is a simple system to accept form data and mail it to a user.

This secure form handler accepts data submitted from arbitrary forms. You do not need to have access to the SSL server in order to use it. You only need to use the secure form handler as the ACTION for your form, and set the "service" and "pgp" fields of your PH information so that the results can be sent to you via encrypted mail.

To see an example of such a form, see

https://www.ecn.purdue.edu/tools/form_handler?help.

Note that this server is currently in testing phase. We have not yet registered with a certification authority. We will appreciate comments about this service.

Secure Setuid Scripts

Other Web applications don't need the security of encryption, but do need to perform privileged operations on the server. Because all CGI applications initially run as user www, the typical way to be able to perform a privileged operation (such as reading or writing a file that is not world-readable/writable) is to set the "uid" bit (see chmod(1)) for a script.

These "setuid scripts" are able to run with many of the same privileges as the users who created them. Unfortunately, in order for the HTTP server to execute the scripts, they must be executable by any ECN user.

For those who aren't willing to trust all ECN users with their scripts, we have developed verifycgi. By verifying the environment of a CGI script, verifycgi can assure that the script is being run through the HTTP instead of by a local user (from the "command line"). (Note that verifycgi is only available on ECN HTTP servers that have been upgraded to Apache. If you are unsure about the status of the server on your machine, use your browser to view http://yourhost/tools/status; non-Apache hosts will give a 404 error. See your site specialist if you want your server upgraded.)

In order to use verifycgi, it should be specified as the interpreter for your script. If your script had a first line of #!/usr/local/bin/perl, the new line would read #!/usr/local/etc/httpd/apache/tools/verifycgi /usr/local/bin/perl

By making this change, you ensure that this script will not run from the command line. This does not, however, keep someone from bypassing security through the HTTP server, so your script should also test the environment variable SCRIPT_NAME to verify that the script is being called as expected.

By using verifycgi, you should be able to safely use setuid scripts to perform privileged operations and know that they are only performed by users who come through the HTTP server - authenticating if required. Script security still requires attention to detail, but this simple tool provides a vital first defense.

For more information, see

http://www.ecn.purdue.edu/ECN/tools/verifycgi/


webmaster@ecn.purdue.edu
Last modified: Tuesday, 14-Oct-97 10:55:04 EST

[HTML Check] HTML