Do I need to filter the $_FILES['file'] before dealing with it?

Question

To protect the websites we're programming from attacks such as SQL-Injection or XSS we need to filter users' inputs before storing or displaying it.

In PHP, we use htmlspecialchars and addslashes functions to the inputs to prevent XSS and SQL-Injection attacks. So, what about the files ?

I used to protect web-apps by checking the files type and it's extension to know if those were in the whitelist or not. But I don't use htmlspecialchars and addslashes functions because I didn't see someone using this approach.

For example, if I want to get the file name I use $_FILES['file']['tmp_name'] then I store it directly to the database.

Is this wrong or it cannot be injected with codes, commands ... etc.

Answer 1

Do I need to filter the $_FILES['file'] before dealing with it?

Short answer: NO. It's a bunch of string values, nothing more.

Long Answer:

I used to protect web-apps by checking the files type and it's extension to know if those were in the whitelist or not.

This is a good approach, if applied and carried out correctly.

the $_FILES array is simply a carrier. It can't itself be abused, but you have to trust what it carries - ie trusting the file that is being passed to/by the server.

---

While I write this answer; below; it seems the OP is confused about what they're actually protecting against and why:

The OP states as "best practise" (which it is absolutely not):

If you want to use $_FILES['file']['tmp_name'] to be stored into your database or to display in your UI, you should use addslashes or PDO prepare statement to be protected against SQL-Injection attacks.

This is a misunderstanding of how the $_FILES array is populated. The $_FILES['file']['tmp_name'] value is set by the server, not by the user or the client.

The user given values are:

$_FILES['file']['name']
$_FILES['file']['type']
$_FILES['file']['size']

These are the string values that would need to be vetted. As long as you do not trust these string values, you have nothing to worry about.

---

Storing files inside your database is not usually a good idea and has its own pitfalls, dhnwebpro has their own answer on this question, regarding database safety.

---

$_FILES['file']['tmp_name'] is the server location of the file in temporary storage space.

The PHP Manual clearly states:

Files will, by default be stored in the server's default temporary directory, unless another location has been given with the upload_tmp_dir directive in php.ini. The server's default directory can be changed by setting the environment variable TMPDIR in the environment in which PHP runs.

The file will be deleted from the temporary directory at the end of the request if it has not been moved away or renamed.

If you think that your $_FILES['file']['tmp_name'] value is being abused then this is a sign of server compromise and you've got a whole lorry load of trouble on your plate, well beyond a nefarious file upload.

---

So, how to vet the file that is being carried?

There are numerous types of file attacks and this topic is far beyond the scope that you are asking. For example; a genuine JPEG image can contain XSS scripting in the JPEG Metadata, but this XSS is triggered when the JPEG is loaded and viewed, but for all intents and purposes the JPEG file is not a "bad file" or is not a XSS file, to an outside observer who doesn't specifically check for this vulnerability.

So, do you block this file.jpg or do you block all Jpeg files? It's a tough call to make but in PHP there are some very good work arounds (which are also I believe out of scope for this question). In short; your question could do with some editing and clarity as to what exactly you're trying to protect against and how far you're willing to go to reach that level of protection.

I can give you a rough catch-all guide to preventing certain MIME file-types from being accepted onto your server. This looks and feels like what you want, something to stop sneaky MP4 videos being uploaded as document files (or vice versa).

1:

Ignore the filename ($_FILES['file']['name']). NEVER trust user data.

Edit: As pointed out by meagar, you may need to retain the original filename, in which case you should check it with a REGEX or similar to remove unwanted characters...

2:

Ignore the declared filetype ($_FILES['file']['type']). Any filename given MIME type (such as .pdf) should simply be ignored. NEVER trust user data.

3:

Use the PHP Finfo function set as a preliminary indicator. It is not perfect but will catch most things.

$finfo = finfo_open(FILEINFO_MIME_TYPE); // return mime type ala mimetype extension
$mimeType = finfo_file($finfo, $_FILES['file']['tmp_name']);
$whitelist = ['text/html','image/gif','application/vnd.ms-excel'];
finfo_close($finfo);
if(in_array($mimeType,$whitelist)){
    // File type is acceptable.
}

4: Images:

If you are checking an uploaded image the best approach is to check the finfo filetype as per 3 and then have PHP load the image into a blank canvas and resave the image, thereby stripping out all the excess metadata and other potentially undesirable data that is not image-data.

Like this method: Remove exif data from jpg using php.

5:

It is also advisable always to give your uploaded files randomised names, never using the $_FILES['file']['name'] value.

6:

Depending on the sort of threat you're trying to avoid and/or neutralise, you can open the uploaded file and read the first few bytes of the file and compare it with confirmed bytes from whitelisted files of that type. This is quite nuanced and again beyond the scope of this answer, which is quite long enough.

Answer 2

There is a function is_uploaded_file to determine that the file is indeed an uploaded file and not some sort of file path manipulation on the user's part. As far as I know, there is no way that is_uploaded_file($_FILES['file']['tmp_name']) will return false. You should also check that the filesize($_FILES['file']['tmp_name']) is less than the size of the column you are inserting into.

As for "storing it directly to the database" you still need practice good SQL injection prevention on the file contents. Additionally, it is usually difficult to scale a solution that stores files in a database, but that is a separate issue that you have presumably considered already.

Answer 3

If you're using PDO or MySQLi you should be able to place the file in a prepared statement which should protect you from SQL injection attacks. I pasted a method from https://www.mysqltutorial.org/php-mysql-blob/ which has some good information on storing files in a MySQL database.

/**
 * insert blob into the files table
 * @param string $filePath
 * @param string $mime mimetype
 * @return bool
 */
public function insertBlob($filePath, $mime) {
    $blob = fopen($filePath, 'rb');

    $sql = "INSERT INTO files(mime,data) VALUES(:mime,:data)";
    $stmt = $this->pdo->prepare($sql);

    $stmt->bindParam(':mime', $mime);
    $stmt->bindParam(':data', $blob, PDO::PARAM_LOB);

    return $stmt->execute();
}

Or you could store the file on the filesystem and just include a reference to the file for when you need to serve it up. This method is quicker, but doesn't have the convenience of keeping all your data in one place.

The details about the elements of the $_FILES array are kind of buried in the manual, but they can be found at the end of example 1 here:

https://www.php.net/manual/en/features.file-upload.post-method.php

The values on all elements of the $_FILES array should be regarded as user input. I would recommend ignoring those values. However, if you wish to write them in to a database and/or display them later in your UI, you definitely need to protect yourself from SQL injection and XSS attacks. So using prepared statements and htmlspecialchars wouldn't hurt, in that case.