The basic philosophy of WN security is that by default no client requests are granted. Permission to serve a document must be explicitly granted by the maintainer. This is done as follows: If the file /dir/myfile is requested the server looks for a file named index.cache in the directory WN_root/dir/. If this file exists and contains a line like
file=myfile&title=This is my file...
then the file myfile can be served. Despite this strong foundation several additional steps are prudent. The most important is that the maintainer must assure that no untrusted source has write access to any part of the WN hierarchy. For example an "incoming" anonymous ftp directory should never be part of a WN hierarchy, because an attacker could put an index.cache file there granting access any file in the hierarchy.
The -t and -T options. There is support for additional optional security against counterfeit index.cache files. This is achieved by specifying a trusted userid or groupid (not both) for index.cache files. To do this use the "-t uid#" or "-T gid#" option to wn or swn. When invoked in this way wn or swn will not serve a document unless the index.cache file listing it has the prescribed owner or gid. This uid# or gid# should be that of the maintainer not the one under which wn or swn runs. Indeed, for security reasons the server will refuse to use an index.cache file whose owner is the uid under which the server is running. If on your server all index.cache files are created by a single user or a single group I strongly recommend using the -t or -T option. This added security is weakened somewhat if you use the -u option which allows index.cache files owned by untrusted users to permit the serving of files owned by the same user.
When the server is run it must assume the permissions of some user on the host. Which user is determined by defining USER_ID in config.h. It is important this USER_ID have as few permissions as possible. On many systems there is a user called "nobody" with minimal permissions and USER_ID equal to 65534. This is a good choice and is the default choice of WN. Of course the server must have read permission on all the files served but it should not have write permission for any directory or file other than its logfile. If the syslog option for logging is enabled there is not even any need for write permission on a logfile. A good practice is to have files in your hierarchy which you intend to serve be owned by the maintainer or their creator. They should be world readable (assuming they are for general consumption) but with restricted write permission. The files in your hierarchy should not be owned by the user id under which WN will run.
WN does not use the chroot system call to further restrict the files which the server can access. Doing so would enhance security at the expense of extra work for the maintainer. The effect of this is to prevent the server from even internally accessing any file which is not in your data directory. If you are especially concerned about security you may wish to run one of the public domain TCP wrappers in conjunction with WN. This will simultaneously enhance security for other TCP services like anonymous ftp.
The second method is for HTML forms using the POST method. In this case everything posted by the client (in URL-encoded form) must be sent to the standard input of the CGI script. Thus if the request is of type POST, information is read from the client and put in a temporary file on disk. Then the script is executed with no arguments and its standard input comes from this file. Security is the responsibility of the script writer. It is not so dangerous to have arguments come from standard input but the script writer must still exercise care.
Finally if the GET request has arguments but no '=' it is assumed to be an ISINDEX type request and the script should be executed with the given arguments. While the CGI specification does not permit the altering of arguments, it does say that if the arguments pose any security problems it is permissible to put the string in an environment variable and execute the script without arguments, just as in the CGI forms case described above. WN takes a very strict position here and views any of the characters in the list
; !` ' | \ * ? - ~ < > ^ ( ) [ ] { } & $ \r \n / or \
as a security problem requiring this action.
If it is possible make sure that no untrusted user has write access to any part of your WN hierarchy. As mentioned above an attacker with write access to your hierarchy can create a index.cache file which will give access to anything in your hierarchy. Even worse, she can create a shell script and a index.cache file permitting it to be executed. A good principle to keep in mind is: Everyone with write access to any part of your data hierarchy has all the permissions of the userid under which your server runs!
Sometimes it is not possible or desirable to deny write access to your WN hierarchy. For example, you may want to allow all users to have a subdirectory of the hierarchy in which to publish their "home pages". There are two important things to do in this case.
The first of these is run the server with the -u option. This has the effect of requiring that every file served (including wrappers and includes) have the same owner as the index.cache file which grants it permission to be served. This means that untrusted users can only serve files which they own. If the -t or -T option (described above) is also used then index.cache files owned by the trusted user or trusted group are exempt from this requirement and they may grant permission to serve any file the server can read. For security reasons the server will refuse to use an index.cache file which is a symbolic link to another file.
The -e or -E command line options mentioned above may be a good idea in this case, to prevent any execution of scripts or at least restrict their execution to trusted index.cache files. You should note that there is no way to use .access files to prevent users on your system with write access to the data hierarchy from gaining access to files you are serving. They can simply make a symbolic link in their part of the hierarchy to the file you want to restrict and a index.cache file permitting it to be served. Since the server has access to the restricted file it will serve it if it is listed in a index.cache file.
The most important thing to remember in this situation is the principle cited above. All users have some permissions and are denied others. Remember that any permissions you grant to the userid under which WN runs are also granted to every user who can create an index.cache file in your data hierarchy.