3

I know there will always be some level of risk when allowing user-submitted data, but what exactly does EE do natively to filter, validate, and sanitize photo uploads through the standard interface? Does EE do anything to escape or sanitize photos on output or before doing any other processing? I'm talking mostly with respect to avatars and the native EE file upload system, particularly pertaining to photos (current EE version 2.8.1).

Researching the developer docs, they have the following to say on saving images to server:

Saving Images or Files to the Server

When saving images or files to the server, make sure and validate the file type (MIME) and also clean the file name to remove possible naughty characters.

  • Sanitize file name: ee()->security->sanitize_filename();
  • Browser provides the MIME type, available in: $_FILES['userfile']['type']
  • Use the Upload class (ee()->load->library('upload', $config);) as it contains methods for validation and sanitizing

I assume that EE's native file upload functions use the Upload class, but what exactly does the Upload class do to validate and sanitize? Does it check MIME type using some sort of actual file analysis, or does it simply rely on what the browser reads it as?

Can anyone give any particular pointers or best practices in EE photo upload settings or possibly server settings to permissions given to the photo upload folder to maintain the highest level of security?

7

I assume that EE's native file upload functions use the Upload class, but what exactly does the Upload class do to validate and sanitize? Does it check MIME type using some sort of actual file analysis, or does it simply rely on what the browser reads it as?

The Upload class uses the $_FILES array and it does use $_FILES[]['type'], but we do some verification later on:

if (function_exists('getimagesize') && @getimagesize($file) !== FALSE)
{
    if (($file = @fopen($file, 'rb')) === FALSE) // "b" to force binary
    {
        return FALSE; // Couldn't open the file, return FALSE
    }

    $opening_bytes = fread($file, 256);
    fclose($file);

    // These are known to throw IE into mime-type detection chaos <a,
    // <body, <head, <html, <img, <plaintext, <pre, <script, <table,
    // <title
    // title is basically just in SVG, but we filter it anyhow

    if ( ! preg_match('/<(a|body|head|html|img|plaintext|pre|script|table|title)[\s>]/i', $opening_bytes))
    {
        return TRUE; // its an image, no "triggers" detected in the first 256 bytes, we're good
    }
    else
    {
        return FALSE;
    }
}

if (($data = @file_get_contents($file)) === FALSE)
{
    return FALSE;
}

$CI =& get_instance();
return $CI->security->xss_clean($data, TRUE);

So we:

  • Make sure that getimagesize() works on the file
  • If the file is an image, we check the first 256 bytes for any funny business
  • Make sure that running Security::xss_clean() returns an untouched file

Can anyone give any particular pointers or best practices in EE photo upload settings or possibly server settings to permissions given to the photo upload folder to maintain the highest level of security?

Well, in order for the images to be accessible on your website, the images must have permissions so the server can access them, which means you at least need read+write access for the server and read access for everything else. Our recommendation in the installation documentation is:

These permissions are typical for PHP-based applications running on Apache, though you may want to check with your web host to see if more restrictive permissions can be used to allow PHP to write to files and directories.

Since every server is different, we're pretty loose on our suggestions, but it doesn't hurt to try more and more restrictive options until you find one that works best for you.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.