4 Replies Latest reply on Nov 4, 2008 2:59 PM by Newsgroup_User

    Best Practices - File Upload

    Level 7
      When running a file upload script from a password protected directory,
      what are the best practices regarding where the file goes and what
      permissions/ownership need to be applied?

      1. Is it OK to upload to the web tree? ie: www.domain.com/uploads
      2. If so, what ownership/permissions should be applied to this
      directory? Is 777 a security problem?
      3. Should the files be uploaded above the web tree? ie: higher than the
      public_html directory?
      4. If this is so, same question as #2.
      5. Also, how does a web page access files higher than /public_html?

      Thank you,
      Harvey
        • 1. Re: Best Practices - File Upload
          Level 7
          On 04 Nov 2008 in macromedia.dreamweaver, eclipsme wrote:

          > When running a file upload script from a password protected
          > directory, what are the best practices regarding where the file goes
          > and what permissions/ownership need to be applied?
          >
          > 1. Is it OK to upload to the web tree? ie: www.domain.com/uploads
          > 2. If so, what ownership/permissions should be applied to this
          > directory? Is 777 a security problem?
          > 3. Should the files be uploaded above the web tree? ie: higher than
          > the public_html directory?
          > 4. If this is so, same question as #2.
          > 5. Also, how does a web page access files higher than /public_html?

          Like so much in web development, it depends.

          For starters, the userid under which the webserver runs[1] is going to
          need write permissission on the directory. 777 would certainly achieve
          that. So would something like changing the group to the webserver
          user, and using 66X.

          As to where to locate it - is it something which somebody will need
          access to before something else is done to it? If not, the best bet is
          a directory outside the site root.[2] Otherwise, somebody who figures
          out the routine can upload, say, "mymalware.zip", and direct people to
          http://example.com/uploaddirectory/mymalware.zip in order to get to the
          file.

          As to your question 5 - it depends on the underlying operating system,
          and how the site is set up. PHP can be given an absolute directory
          path, relative to the server's filesystem, not the site's.[3] This
          code creates a new directory under /usr/uploads based on the current
          date/time:

          <?php
          // Set some parameters
          $basepath = '/usr/uploads/';
          $maxUploadFiles = 5;
          if ($_SERVER['REQUEST_METHOD'] == 'POST') {
          // Set up a directory name based on current date/time
          $whatdirectory = date('Ymd-His');

          // Create a new directory for this upload
          mkdir($basepath . $whatdirectory);
          ...

          As long as the webserver has permission on the directory (and you do,
          too, in order to retrieve the files, you can put the uploaded files
          anywhere in the filesystem.

          [1] Usually apache or www-data; NOT the owner of the site
          [2] This can be above the site root, or parallel to it
          [3] I assume that this is also true for IIS; someone more familiar with
          it will have to comment

          --
          Joe Makowiec
          http://makowiec.net/
          Email: http://makowiec.net/contact.php
          • 2. Re: Best Practices - File Upload
            Level 7
            Joe Makowiec wrote:
            > On 04 Nov 2008 in macromedia.dreamweaver, eclipsme wrote:
            >
            >> When running a file upload script from a password protected
            >> directory, what are the best practices regarding where the file goes
            >> and what permissions/ownership need to be applied?
            >>
            >> 1. Is it OK to upload to the web tree? ie: www.domain.com/uploads
            >> 2. If so, what ownership/permissions should be applied to this
            >> directory? Is 777 a security problem?
            >> 3. Should the files be uploaded above the web tree? ie: higher than
            >> the public_html directory?
            >> 4. If this is so, same question as #2.
            >> 5. Also, how does a web page access files higher than /public_html?
            >
            > Like so much in web development, it depends.
            >
            > For starters, the userid under which the webserver runs[1] is going to
            > need write permissission on the directory. 777 would certainly achieve
            > that. So would something like changing the group to the webserver
            > user, and using 66X.

            Is one more secure than the other?

            > As to where to locate it - is it something which somebody will need
            > access to before something else is done to it? If not, the best bet is
            > a directory outside the site root.[2] Otherwise, somebody who figures
            > out the routine can upload, say, "mymalware.zip", and direct people to
            > http://example.com/uploaddirectory/mymalware.zip in order to get to the
            > file.

            These files are then listed for viewing (pdf) or playing (mp3). So, how
            do you stop the possibility of malware?
            >
            > As to your question 5 - it depends on the underlying operating system,
            > and how the site is set up. PHP can be given an absolute directory
            > path, relative to the server's filesystem, not the site's.[3]

            This is Unix. I currently have this set up like this
            /usr/public_html/agency/agendas/, so the link is of course
            /agency/agendas/.

            I am having trouble getting my host to make this directory belong to the
            nobody group - am I saying that correctly? So currently the only way I
            have of running the script is by setting permissions to 777. This seems
            to be the prelude to the malware issue above, right?

            Would it be better to create /usr/agency/agendas, upload to there and
            access them as you say with a $basepath = '/usr/agency/agendas/'? Will I
            still have the permissions problem?

            Harvey
            • 3. Re: Best Practices - File Upload
              Level 7
              On 04 Nov 2008 in macromedia.dreamweaver, eclipsme wrote:

              > Joe Makowiec wrote:

              >> For starters, the userid under which the webserver runs[1] is going
              >> to need write permissission on the directory. 777 would certainly
              >> achieve that. So would something like changing the group to the
              >> webserver user, and using 66X.
              >
              > Is one more secure than the other?

              Well, for starters, the ones with 6 in them eliminate the execution
              bit. (The X in 66X, btw, stands for 'any digit 0-7'.) If you can get
              the directory group to be that of the webserver user, then 664 would
              allow read and write to you and the webserver, and only read to the
              general public.

              >> As to where to locate it - is it something which somebody will need
              >> access to before something else is done to it? If not, the best
              >> bet is a directory outside the site root.[2] Otherwise, somebody
              >> who figures out the routine can upload, say, "mymalware.zip", and
              >> direct people to http://example.com/uploaddirectory/mymalware.zip
              >> in order to get to the file.
              >
              > These files are then listed for viewing (pdf) or playing (mp3). So,
              > how do you stop the possibility of malware?

              Do checking in your upload script for file extensions; only allow .pdf
              or .mp3. That doesn't stop it, but it does slow it down.

              >> As to your question 5 - it depends on the underlying operating
              >> system, and how the site is set up. PHP can be given an absolute
              >> directory path, relative to the server's filesystem, not the
              >> site's.[3]
              >
              > This is Unix. I currently have this set up like this
              > /usr/public_html/agency/agendas/, so the link is of course
              > /agency/agendas/.
              >
              > I am having trouble getting my host to make this directory belong to
              > the nobody group - am I saying that correctly? So currently the only
              > way I have of running the script is by setting permissions to 777.
              > This seems to be the prelude to the malware issue above, right?

              Yes.

              Do you have terminal access to the server? If so, SSH in and run this
              command:

              [me@myserver ~]$ chown {myusername}:{apacheusername} agency/agendas

              where {myusername} and {apacheusername} have their appropriate values.

              > Would it be better to create /usr/agency/agendas, upload to there
              > and access them as you say with a $basepath =
              > '/usr/agency/agendas/'? Will I still have the permissions problem?

              Do you have access to /usr ?

              --
              Joe Makowiec
              http://makowiec.net/
              Email: http://makowiec.net/contact.php
              • 4. Re: Best Practices - File Upload
                Level 7
                Joe Makowiec wrote:
                > On 04 Nov 2008 in macromedia.dreamweaver, eclipsme wrote:
                >
                >> Joe Makowiec wrote:

                >
                > Well, for starters, the ones with 6 in them eliminate the execution
                > bit. (The X in 66X, btw, stands for 'any digit 0-7'.) If you can get
                > the directory group to be that of the webserver user, then 664 would
                > allow read and write to you and the webserver, and only read to the
                > general public.

                Yes, this is what I am trying to do but for some reason it seems above
                the comprehension of the level 1 techs. I have asked them to change
                ownership of the group to nobody, but no luck yet.
                >

                >
                > Do checking in your upload script for file extensions; only allow .pdf
                > or .mp3. That doesn't stop it, but it does slow it down.

                Yes I am doing this.
                >
                >
                > Do you have terminal access to the server? If so, SSH in and run this
                > command:
                >
                > [me@myserver ~]$ chown {myusername}:{apacheusername} agency/agendas
                >
                > where {myusername} and {apacheusername} have their appropriate values.

                No i don't, but I may be able to get it turned on - not sure. With my
                limitedknowledge of unix I am not sure this would be the best idea...
                >
                >> Would it be better to create /usr/agency/agendas, upload to there
                >> and access them as you say with a $basepath =
                >> '/usr/agency/agendas/'? Will I still have the permissions problem?
                >
                > Do you have access to /usr ?
                >
                Yes, I do. Through FTP.

                Harvey