Re: Don't allow users to upload files

[Wade Evans <wade.p.evans@xxxxxxxxx>]

Hugo,

If you are allowing users to upload files, and you also have content type handlers and activated modules for executing scripts, you are creating a big window of opportunity for your site to get hacked.

In the specific example you cite (PHP), you can do something about it by focusing on the php module's configuration.  For example, you might try adding the "file handling" family of functions to the list of functions that are forbidden.  That might make your implementation safe and it might not.  Your first indication that it isn't keeping you safe would come from you recognizing that new files are in place or that existing files had been modified -- and by then it may well be too late.  In the meantime, users will be finding scripts (perfectly innocent scripts, as far as they and you are concerned) are not working as expected due to the turned-off functions.  Your users are not happy, and your site is not secure, and you are spending more and more time thinking about it instead of whatever other activity comprises the rest of your normal workflow.

Are there other script languages that you allow?  Python, perl, etc?

Do you want to run around to each script module's configuration, trying to guess what code a malicious user might executing on your system, and then attempt to tweak the configuration to disallow that bad activity?

If you allow users to have arbitrary files on your web host due to your decision to mirror their home directory, turn off your scripting modules and deactivate those content types.  If you do that, a PHP script becomes just another text file that ends in "php", not a potential bomb waiting to go off in your face.

"But what if I need all these scripting modules installed to run some other software I like?"  I suppose you could allow the scripting to be enabled, but attack the problem from the other end: the files.  Look at the software you are using to do the mirroring, and configure/modify it to ignore (as in, NOT MIRROR) files with extensions that map to script processors.  For this to work, you have to ban every file name that could end up being presented to the script module for execution.

Bottom line: If you allow users have arbitrary files to your server, files that anyone can execute with a HTTP request, you are asking for trouble.  Other files getting uploaded is not the only bad thing that can happens to your site, it's just one of many possible approaches to breaking what is a fundamentally insecure setup.

Don't do it.

Cheers,

-w

On Thu, Oct 20, 2011 at 5:53 AM, Hugo Gomes <hugo@xxxxxx> wrote:

Hi all,

       I have a webserver where the users homes are copied to a folder, and I
want to assume that users can not make a script (for instance .php) to
let upload files.

       In my httpd config file i have this directive that assumed it was
enough, but now i saw that people can still upload files with some .php
scripts that users have in their home.


 <Limit GET POST OPTIONS PROPFIND>
       Order allow,deny
       Allow from all
 </Limit>
 <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>
       Order deny,allow
       Deny from all
 </Limit>


       What configuration directive can i insert in the config file to don't
allow users could upload files to their homes through php scripts
(move_uploaded_file)


       Best regards,
       Hugo Gomes

--
*************************************************
    Hugo Gomes
    LIP
    Av. Elias Garcia 14, 1º
    1000-149 Lisboa, Portugal
    Telef.:  +351- 217 998 587
    URL: http://www.lip.pt
    E-mail: hugo@xxxxxx
*************************************************


---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx