cgi.pm file upload script

[wolverina]

I found a upload utility using cgi.pm. The script
works fine.. i can see data uploading, and the
script says successful, but when i look at the
directory on my isp the file is suppose to upload
to.. there is nothing there. Permissions are set
to 777. Any idea's? Also, i'm wondering how a
script can log into my isp and upload a file,
even though the script does not require any variables
that need my ISP's userID and Password. I found the
script here: http://www.onlinearts.net/showroom/takethis.
If it worked, it would be really cool. I seem to have
the worst luck. If spent a month messing around with
net::ftp, could never get the info i needed. Read some
posts that said it had to be installed at my ISP. Other
posts said it's installed on the client.. go figure.
Anyhow, if someone could enlighten me, that would be
great. Wagging tail.

-Lisa

[grep]

From what I can see... ditch this script.


• It is for a "PERL 5-enabled web site". What ever that is :)
  
• It uses cgi-lib, this is terrible. It is perl 4 code and has not been supported for 4 to 5 years
  
• They are making you pay for it (not that I am against that, but that is usually a red-flag to me that these guy/girls do not know what they are doing, especially since the functionality is trivial).
  
• The functionality they offer is minimal.
  
• and the topper is they require permissions at 777. (if you had this on my server I would shut down your account)
  
  Run, don't walk away from this script.
  
  UPDATE: this is basically parsing routine

  my $cache = 'blah=hi;cat /etc/passwd';
  
  @pairs = split(/&/, $cache);
  foreach $pair (@pairs) {
      ($name, $value) = split(/=/, $pair);
  
      $value =~ tr/+/ /;
      $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
  
  
      if (defined($FORM{$name})){
          $FORM{$name}.="\0";
      }
  
      $FORM{$name} .= &strip($value);
  
  }
  
  sub strip {
  
       my($cheese)= @_;
         $cheese =~ s/\t/ /g; 
       $cheese =~ s/\|//g; 
       $cheese =~ s/\r//g;   # should use this.
       $cheese =~ s/\n/<P>/g;   # should use this.
       $cheese =~ s/%95/<li>/g;
       $cheese =~ s/"<P><P>"/<P>/g; 
        return ($cheese);
  }
  

  Pardon me if I'm wrong but this does not strip out ;'s which gets really bad since I just spotted.

   $directory_size = `du -s $target/$where `;
  

  
  
  grep

  grep> cd pub grep> more beer

[wog]

Desipte your impressions, this set of scripts is written with the older cgi-lib.pl library (as mentioned by grep) and a handrolled form parser (update: and, of course, not the reccommend CGI module). (Why include a library that does something and do it again? Beats me.)

More importantly, these scripts contain potentially serious security holes. They often use form input directly from the web browser in forming filenames which are then written to or deleted. This means that through these scripts someone could potentially overwrite or delete any file your script has access to. Even worse, this script will, under some circumstances (update: the hole grep found will probably allow that most of the time. I found another (`echo "$body" | $mail ...`) which would probably not be so common, being dependent on the setting of what mailer to use), include user input as part of a shell command. This means that someone could probably even run arbitrary shell commands on the system (e.g. rm -rf / to remove all files the script can remove).

As for the coding style, these scripts are similarly bad. The idention is horribly inconsistent. They don't use warnings and strict, let alone taint checking. They don't check the return value of many system calls (e.g. open, unlink). Variables are "declared" with both local and my -- only one should be used, ideally my, since this script intends to run on perl5 systems (as evidenced by the perl5-only use statement). (because my wasn't introduced till perl5, local was typically used in the same way in perl4 which is at least 8 years out of date.)

This program also uses syntax like this for prototypes:

sub sendmailer($recipient, $sender, $subject, $message){

This syntax is not supported in any written version of perl.

update: Elaborating on a point grep made, requiring 777 permissions could also be considered a security flaw: it lets pretty much anyone else on the web server you are using mess with the files this script is managing. In almost any way they want to.

[cLive ;-)]

I put a simple upload script here a while back.

Why not try to use that as a basis for your upload script and then get back to us if you have any problems.

You might also find it useful to read up on the CGI.pm module.

I don't know what server you're on, but if you're on a Cobalt RaQ, set permissions to 755 for the directory instead, it's a lot safer.

cLive ;-)

ps - in answer to your question about how does it log in, it doesn't. I think you need to read a bit more background info on how CGI works - this is a good book to get you going. You might as well be asking how a web browser logs in to your server to get a web page. Read the explanation of CGI for a bit of background info. In fact, Amazon even have the relevant info online

[wolverina]

I realize the script is not secure because of
the permissions. I was only considering it out of
desperation since i could not get net::ftp to
work. Can you confirm whether net::ftp
is required on the ISP's server, or on the client
(my computer)? Ive had conflicting info in regards
to that issue. Thanx much.

-Lisa

[cLive ;-)]

Browser Requests Object using GET or POST method, eg:

GET http://www.domain.com/some/file

Server 'maps' domain name to directory and looks for object, eg:

/home/sites/mysite/web/some/file

If found, server looks at extension.

Is it .htm or .html? It's a web page, so return appropriate content header and send the page to the browser.

Is it executable? Server checks against list of file types it's been told it can run. May be .cgi, may be .pl, may be both or more.

If it can run it, it then tries to run it.

".. the browser is retrieving a file, not uploading one, which in my experience all- ways requires an Id and password to log in first."

There are several things here I think you're confused about. I think you need to think about the protocols (the ways you are talking to the server). When you upload your web site files to the server, you are using FTP, and your account requires a login and password to upload and download files¹.

With HTTP, when you are uploading a file, you are essentially sending a page request and attaching a block of data. The upload will only work if you have installed and configured the upload script by FTP¹. - ie, you needed a login/password to tell the server you want to use this script (that's the FTP part) and where you want it to dump the file that's uploaded - along with other security checks, like maximum file size (that's the Perl part).

You can force users to enter a username/password at upload time, but then you need to store passwords securely, or use .htaccess to control access to the pages - and that's another story.

Clear as mud now, eh? :-) From the way you are wording your questions, I think you need to learn quite a bit more before you can safely and securely let yourself loose on an upload script. At the very least, post the code you are going to use at some point and ask people to check whether it's secure or not.

But as I said before, read those pages on Amazon, and buy the book if you can afford it - and Learning Perl might be useful too.

hth

cLive ;-)

¹ Yes, you can have anonymous FTP, but I'm trying to keep it simple for your example. And let's not get into SSH, Telnet etc...

[seattlejohn]

You say that you can see the data uploading but can't see the data when you look on your ISP. Are you actually looking at the raw directories and files on your ISP (e.g. via a telnet client), or are you trying to look for the uploaded file/page on your Web site? The reason I ask is that FTP files and Web pages often live in different portions of the directory structure, so the file may have been uploaded correctly, just not to where you expect it. Also, some web hosts will allow you to upload files into a directory, but not, in general, to view/download files once they are uploaded. This is a security precaution intended to prevent script kiddies from using your ftp space as an illegal file-exchange service. In any case, and as others have pointed out, you want to be really careful with security issues when you're allowing uploads to your site for any reason.

Good luck!