From: David D. Kilzer (ddkilzer@raytheon.com)
Date: Tue Apr 20 1999 - 18:53:30 CDT
This would probably be the safest solution, though it would obfuscate
the names of the files if you were to look in the hypermail-generated
directory itself.
This could easily be accomplished using a simple CGI script that is
passed the MIME type (as known or guessed when Hypermail is run) and the
saved filename, and which uses the special "PATH_INFO" trick to make the
original filename available.
An example of an absolute URL for a web site would look like this:
/cgi-bin/hmdownload.cgi/realfilename?mime_type=image%2Fgif&saved_file=binNNNNN
where "/cgi-bin/hmdownload.cgi" is the actual CGI script, "realfilename"
is what the user's web browser sees as the actual filename, the
"mime_type" variable is the MIME type of the file (if known), and the
"saved_file" is the generated name of the attachment.
The CGI script should have a configuration setting that only lets it
look for attached files in a given directory, and it should to do some
sanity checking to prevent abuse, like setting "saved_file" to
"../../../etc/passwd" or similar.
This may be more trouble than it's worth, though, and simple filename
mangling (like prepending "x-") might be better.
Dave
On Tue, 20 Apr 1999, Craig A Summerhill <craig@cni.org> wrote:
>I just thought of a fifth (5) possible approach... maybe.
>
>You might be able to use some kind of global hypermail cgi script
>(presumably installed in the master /cgi-bin directory as defined
>by cgidir in the top level Makefile) to mask the path name of the
>MIME attachments which are being called/written. I have seen some
>servers do something like this with CGI or JavaScript. If you
>examine the HTML of the files, there is no indications of the
>real path to the file. But clicking on an icon or hyperlink causes
>a server-side handler to serve the file up. Presumably, it could
>be as easy as a Perl script which does
>
>sub ServeItUp {
>
> print <<EOF;
>
>Content-type: $mime-type
>
>stream the file
>
>}
>
>I'll try to think this out some more, but I think you could securely
>make the attachments available to clients and effecitvely prevent
>crackers from getting into the server. Even if they write some kind
>of 'bad' file to the server, they probably can't do much with it unless
>they know the path...