Re: sanitizing uploaded data with a form



NN wrote:

On Tue, 14 Oct 2008 15:11:33 -0700, Tim Greer <tim@xxxxxxxxxxxxx>
wrote:

NN wrote:

I have a form that i'll be using to upload images to my server. i'm
concerned about the possibility of entering wrong data into my
database (mysql) or the user choosing a file name not compatible
with Linux/apache.

i'm escaping quotes for the database, but i wasn't sure what other
precautions i should take as far as the file name is concerned
(which i'd like to keep intact if possible).

i'm already filtering the mime types this way:

$allowedFileTypes = array("image/gif", "image/jpeg", "image/pjpeg");

if (!in_array($_FILES['data']['type'], $allowedFileTypes)) {
die("ERROR: File type not permitted");
}


thank you very much for your help,
NN

Checking the headers of the file itself are always a good idea. There
are really no file names that aren't compatible, but that's a long
discussion to get into. Check the file name and file extension,
ensure they can only use alphanumeric charcaters and a dot + file
extension. You can always (and probably should) rename their file to
some numeric
file name with the correct file extension. I.e., "this's my
wedding.jpg" to 01435664634.jpg (maybe by time and seconds), or
whatever you want. For their title/description, you can escape things
like new lines, single quotes, etc.

Anyway, be sure they can't start a file name with a . and that they
can't add non alphanumeric characters, such as / $, %, etc. It really
also depends if your script will try and interpret meta characters on
uploads or just displaying (which it shouldn't ever need to do or want
to do). If the script is to display them, and not display them
directly, you can remove web access to the files. You can deny
permission to view the files direct them, or put them outside of the
web root directory.

You should disallow execution on that directory of any files,
especially if it's directly web accessible, so someone can't upload a
script, especially someone else on the server, if you use a shared
server and the admins allow PHP scripts to all run as the same global
web server user (because that would open the likely potential that
someone else on the server could write a file in your directory and
access it from your
web site, being in your web root). That can easily be overcome, but
it's something to consider if your web host runs PHP in the Apache API
without some wrapper to ensure that only scripts owned by your user
can run in your account and that you don't have to allow world
writable
permissions, for example. There might be more to this and other
suggestions, but it depends on your environment and how things are
configured, including, of course, the PHP upload script itself.
Measures always need to be taken to ensure abuse can't happen, but it
can be done safely.

thank you Tim for your answer.
reading your email i'm thinking that perhaps it is a good idea to
rename the files to with some random characters generated from the
timestamp (using MD5).
even though this interface is for an administrator to upload a photo,
i can never be sure that they will not name a file in such a way that
will break the code, or in a way that will overwrite an existing
photo, so the timestamp solution wil take care of all that.

Be sure that you have the script check if a file name already exists by
the same name before it writes it, if that's a concern.

as for the /uploads directory, i was thinking of using this on the
.htaccess:
Deny from all

That would be a good idea if you won't need direct web access, though a
completely fail safe method is to have it outside of the web root.
Either way is fine, and just be sure that you don't use Limit for GET
POST HEAD, etc., because you have to list the denied request methods,
so just deny from all without Limit, unless you have a specific reason,
so it'll cover all methods.

But i think i'm going to also disallow any kind of execute privilege
to avoid any problems.


Good to hear. There are a few things to do that benefit you regarding
security, but as you can see it's a pretty easy way to do it, once all
of the basic checks are in place, assuming there are no holes in the
script someone can use to bypass those security checks and settings, of
course, so it will still come down to the script.
--
Tim Greer, CEO/Founder/CTO, BurlyHost.com, Inc.
Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers
and Custom Hosting. 24/7 support, 30 day guarantee, secure servers.
Industry's most experienced staff! -- Web Hosting With Muscle!
.



Relevant Pages

  • Re: sanitizing uploaded data with a form
    ... i'm escaping quotes for the database, but i wasn't sure what other ... If the script is to display them, ... especially someone else on the server, if you use a shared server and ... Shared Hosting, Reseller Hosting, Dedicated & Semi-Dedicated servers ...
    (alt.php)
  • Re: Same Internal Server Error from last two days
    ... I am trying to run a Hello World Perl Script in Apache 2.2. ... But its constantly giving me Internal Server Error.The script ... # have to place corresponding `LoadModule' lines at this location so the ...
    (perl.beginners)
  • Re: Same Internal Server Error from last two days
    ... I am trying to run a Hello World Perl Script in Apache 2.2. ... But its constantly giving me Internal Server Error.The script Runs perfectly fine from the command prompt. ... # This is the main Apache HTTP server configuration file. ... LoadModule actions_module modules/mod_actions.so ...
    (perl.beginners)
  • Same Internal Server Error from last two days
    ... I am trying to run a Hello World Perl Script in Apache 2.2. ... But its constantly giving me Internal Server Error.The script ... # have to place corresponding `LoadModule' lines at this location so the ...
    (perl.beginners)
  • Re: Order form with javascript & php files will not work in FrontP
    ... Are you working local and publishing or live on the server? ... It's possible that editing your files local and then publishing is somehow ... > The script files are separate files from the actual form file. ... upload these files to my site ...
    (microsoft.public.frontpage.client)