Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Re: Re: Vetting a CGI script

by hmerrill (Friar)
on Nov 13, 2003 at 14:48 UTC ( #306805=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Vetting a CGI script
in thread Vetting a CGI script

Ok, I see how they were able to take over the machine in that example, but assuming you *have* to offer file upload, how can you protect against that? It's been a long time since I've worked with CGI's that offer file upload capability, and I think when we did, we handled it with CGI.pm. I don't recall specifying a "temp" directory. Is the solution to the problem you presented fixed by specifying a temp directory that is *NOT* the cgi-bin directory?

I just read some in 'perldoc CGI' - there's a section titled "-private_tempfiles" that describes security issues with file uploads and the snifibility of info being written to those temp files.

I guess I'm wondering what the *right* way to program file uploads - is using CGI.pm to do that a good way?

TIA.


Comment on Re: Re: Re: Vetting a CGI script
Re: Re: Re: Re: Vetting a CGI script
by jdtoronto (Prior) on Nov 13, 2003 at 15:51 UTC
    Hi hmerrill,

    Well, you are asking me to stretch back into history. The raid took place in late 1997 and the cgi would have been written between late 1996 and mid-1997. It is in fact quite possible that cgi-lib.pl (Which was a popular predecessor to cgi.pm, written by Steve Brenner of Stanford and last updated in 1999).

    The cgi.pm documentation says: "temporary files are created in /usr/tmp or /tmp and should be deleted automatically." Assuming this is the case there would be little to worry about. Using the PRIVATE_TEMPFILES is a nice trick, at least on *nix systems where the trick works.

    As I recall cgi-lib.pl had some user specifiable variables in the first few lines of code. One that I was always chagning was the maximum file size, but there was also one to specify where the file was written. I think this was the vulnerability. The cgi-lib variable wrote files into a directory that was executable under cgi-bin.

    The moral of the story is that you need to think before you do ANYTHING! Currently I use CGI.pm through CGI::Application under mod_perl. But there are alternatives, most notable CGI::Upload which I have never used. As to the right way? Thou dost speak heresay! Any way is good, there is no right way, but many wrong ways. Make sure you know where temp files go. Make sure that you somehow 'untaint' anything you get from a user - even files.

    jdtoronto

      Thanks - excellent explanation!
Re: Re: Re: Re: Vetting a CGI script
by iburrell (Chaplain) on Nov 13, 2003 at 19:47 UTC
    Definitely use CGI.pm when doing file uploads. It handles all the details.

    It also writes the uploads to temp files. Since these are randomly named and placed in a temporary directory, these won't overwrite anything important. CGI.pm also takes care of removing the temp files once the script is done. With '-private_tempfiles', the file is deleted right after it is created so that nobody else can read. Only the process with the open filehandle can read it.

    CGI.pm also imposes size limits on uploads. This makes it harder for attackers to fill up the disk or slow down the network connection.

    The next thing to consider is what happens with the uploaded file. Usually it gets copied someplace. It is important that the destination be controlled by the script and not by the uploaded file name. It is a good idea to hard code the destination directory. It should be separate from any script directories. It is also a good idea to keep the uploads separate from the static files. If the filename included with the upload is going to be used, it must be sanitized to remove dangerous characters and any path components.

    Finally, most uploads should only be allowed to authenticated users. Allowing uploads from anonymous users is usually a bad idea.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://306805]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (16)
As of 2014-07-24 18:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (164 votes), past polls