PERL CGI Beginners - Upload dir permissions

Author

Upload dir permissions

Ed Pigg

2004-11-19, 3:55 pm

Hi all,

I'm trying to setup a system where users can upload images to a
designated uploads dir. Once the file is successfully uploaded I want
to transfer it to an image directory with a filename I have assigned. I
can do those things with by current application. I needed to change the
permissions of the upload dir to world writable in order for this to
work. I'm not exposing the development system to the internet, so I can
do this now while testing the application, however I want to make sure
that I'm not exposing the upload dir or final image dir to mischief.

Do I need to make the webuser part of a group that will have write
access to the dir's? What are the best practices for this type of
thing.

Thanks

Ed

Chasecreek Systemhouse

2004-11-19, 3:55 pm

On Fri, 19 Nov 2004 11:50:41 -0600, Ed Pigg <ed@questinformation.com> wrote:
> Hi all,
>
> I'm trying to setup a system where users can upload images to a
> designated uploads dir. Once the file is successfully uploaded I want

Keep account creation and uploads separate functions.

> Do I need to make the webuser part of a group that will have write
> access to the dir's? What are the best practices for this type of
> thing.

Yes; here is soemthing to get you started -- change server/directpry
references as approppriate:

#!/usr/bin/perl

use CGI;

# Set to YOUR correct upload area -- must be WWW accessible.
$upload_dir = "/home/insecuri/public_html/forsaken";
# For this example, see http://forsaken.insecurity.org/

$query = new CGI;
$filename = $query->param("photo");
$upload_filehandle = $query->upload("photo");

# SiteID directory path MUST already exist!
$SiteID = $query->param("SiteID");

# Clean it up...
$filename =~ s/.*[\/\\](.*)/$1/;

open UPLOADFILE, ">$upload_dir/$SiteID/$filename";

while ( <$upload_filehandle> )
{
print UPLOADFILE;
}

close UPLOADFILE;

print $query->header ( );
print <<END_HTML;

<HTML>
<HEAD>
<TITLE>Thanks!</TITLE>
</HEAD>

<BODY>

<P>Thanks for uploading your photo!</P>
<P>Your SiteID: $SiteID</P>
<P>Your photo:</P>
<img src="http://forsaken.insecurity.org/$SiteID/$filename" border="0">

<hr noshade><pre>Debug:

$filename
$SiteID
$upload_filehandle
$upload_dir

</pre>
</BODY>
</HTML>

END_HTML

__END__

The HTML portion:

<HTML>
<HEAD>UpLoader Test</HEAD>
<BODY>
<FORM ACTION="/cgi-bin/uploadFile.cgi" METHOD="post"
ENCTYPE="multipart/form-data">
Photo to Upload: <INPUT TYPE="file" NAME="photo">
<br><br>
Enter a SiteID* (or leave blank for main site): <INPUT TYPE="text"
NAME="SiteID">
<br><br>
<INPUT TYPE="submit" NAME="Submit" VALUE="Submit Form">
</FORM>

<hr noshade>
<PRE> SiteID must have been previously defined by Site webmaster, to
include correct directory creation.
</PRE>
</BODY>
</HTML>

Enjoy.

--
WC -Sx- Jones
http://insecurity.org/

Ed Pigg

2004-11-19, 3:55 pm

On Nov 19, 2004, at 12:10 PM, Chasecr

Systemhouse wrote:

> On Fri, 19 Nov 2004 11:50:41 -0600, Ed Pigg <ed@questinformation.com>
> wrote:
>
> Keep account creation and uploads separate functions.

In this case the user will not have a separate site or account.
Appropriate authenticated users will be able to upload images.

>
>
> Yes; here is soemthing to get you started -- change server/directpry
> references as approppriate:

Thank you for the example.

I am able to upload the image file already. That part I have figured
out. What I'm more concerned about is setting appropriate permissions
on the upload dir, so that the web application can write to it but not
so much that I'm needlessly exposing the directory to the outside
world. I want to open the door just enough to get the job done by the
web application and no more. Is that clear? It's not strictly a Perl
question unless I need to get the application to change.

I want to make sure that I am taking the site security seriously and
don't expose it to threats needlessly.

Thanks

Ed

Chasecreek Systemhouse

2004-11-19, 3:55 pm

On Fri, 19 Nov 2004 12:29:21 -0600, Ed Pigg <ed@questinformation.com> wrote:

> I want to make sure that I am taking the site security seriously and
> don't expose it to threats needlessly.

=) You have taken a step into a largewr world. Welcome =)

The Internet is not a secure place. Securely creating a directory for
UserX is a file systems issue -- research how you can see a users
files on the file system without changing them -- then you have a path
toward a solution.

The reason I mentioned account creation as the file systems security
is appropriate for extended WWW security. However, allowing users to
upload files is always a risk -- only time will tell if your best
practices are secure enough.

Generally speaking, the W3 Security FAQ is a great place to start research.

--
WC -Sx- Jones
http://insecurity.org/

Ed Pigg

2004-11-19, 3:55 pm

On Nov 19, 2004, at 12:37 PM, Chasecr

Systemhouse wrote:

> On Fri, 19 Nov 2004 12:29:21 -0600, Ed Pigg <ed@questinformation.com>
> wrote:
>
>
> =) You have taken a step into a largewr world. Welcome =)
>

Thanks. As always, it is not a matter of whether or not the task can be
done, it's whether or not it can be done in a secure manner. I'll check
out the W3 Security FAQ's.

Ed

google@taxandfinance.com

2004-11-19, 3:55 pm

I am creating my first cgi app and it has file uploads. I'm not sure
about best practices, but I can tell you what I've been thinking.

I don't believe the upload directory needs to be world writeable, just
writeable by the httpd process...in my case I made the www user owner
and retained the normal 755 permissions. In a typical Internet facing
web server environment (i.e. not really multi-user) I'm not sure it
matters though. I think the concern would be local accounts having rwx
to that directory. For example, would a compromise of some other [non
root] service on the box result in an attacker being able to write to
that directory?

Some other things to consider: Only allow the file types you expect (in
my case text documents). Limit the upload size to some reasonable
amount using $CGI::POST_MAX. How you will make sure uploaded file names
are unique to keep users from stepping on each others files (for
example, uploading a file with the same name that is actually a virus)?
My application is for internal use only...so I'm debating how far to
go with this currently. I'm probably going to append some part of
sessionID to the file. I have even considered setting the 'immutable'
bit on uploaded files to keep them being overwritten/modifed. I
haven't thought this through all the way though, and it's certainly not
very portable. It might be enough to make sure the files are only
read/execute until such time that they need to be deleted.

Anyway, those are my current thoughts...hope that helps. Let me know
if you come accross some good best practices.

Matt

M. Kristall

2005-04-12, 3:55 am

Ed Pigg wrote:
>
> On Nov 19, 2004, at 12:10 PM, Chasecr

Systemhouse wrote:
>
>
>
> In this case the user will not have a separate site or account.
> Appropriate authenticated users will be able to upload images.
>
>
>
> Thank you for the example.
>
> I am able to upload the image file already. That part I have figured
> out. What I'm more concerned about is setting appropriate permissions on
> the upload dir, so that the web application can write to it but not so
> much that I'm needlessly exposing the directory to the outside world. I
> want to open the door just enough to get the job done by the web
> application and no more. Is that clear? It's not strictly a Perl
> question unless I need to get the application to change.
>
> I want to make sure that I am taking the site security seriously and
> don't expose it to threats needlessly.
>
> Thanks
>
> Ed
>
Typically on a Unixish system with no extra services running that will
enable any type of normal access, you can set permissions however you
want and, aside from write errors (when you've disallowed yourself from
writing) and 5xx errors, you will be fine. Users are only permitted as
much access as the server allows (so don't use IIS or you are
potentially giving full system access to anyone willing to take it). If
you are concerned, you can set limits with apache (if you have access).
<LimitExcept POST GET>
Deny from all # or Require valid-user
</LimitExcept>
for example.

Sponsored Links