$_POST and $_FILES Together and TMP File Name

[PCHome]

I’ve done this many times in the past but am drawing a blank now on how to make it work. File uploads are working with details about the upload that I can get from the $_FILES array, such as the file name name, being inserted into the database as a record of the upload but I need to post other information along with it from the $_POST and that’s where I’m having difficulty wrapping my head around. Partially because this time my sites have a function that generates the prepared statement from the array (filtering out what is not needed) but also because I’ve not done it in many years.

It seems to me that I need to merge the $_POST and $_FILES together into a single array which I have done, then work from there but before I go too far, I need to be sure that this is the proper way or at least an acceptable way, especially as I notice that the tmp file name uses different naming convention than it has when reading the $_FILES array alone. It was never preceded by php before.

Incidentally, I’ve never concatenated arrays together this way but found it online and thought I would give it a test. It was a surprise that it actually worked!

Combining them with this:

$FileArray = $_POST + $_FILES;
$FileArray  = array_flatten($FileArray);

gives this:

Array
(
    [PageUse] => 19
    [ImageCaption] => This is a test
    [SortOrder] => 7
    [files] => Upload File(s)
    [name] => 00-00_0021.jpg
    [full_path] => 00-00_0021.jpg
    [type] => image/jpeg
    [tmp_name] => /tmp/phpNtcSSx
    [error] => 0
    [size] => 3463396
)

[phdr]

This is not general purpose, reusable. If you ever have multiple uploaded files (different field names) or any post/file field is an array name (your last thread had a multiple attribute in the type=‘file’ field, which requires an array name for it to actually work), it doesn’t produce the result you expect.

You would be better off just assigning $_FILES to a named element in the data - $_POST['FILES'] = $_FILES;

@PCHome

(filtering out what is not needed)

As previously posted -

@phdr

Take a proactive approach, where you define an array of the expected fields and their characteristics for any operation, rather than a reactive approach of trying to remove or filter out the things that you don’t want, which will miss things that hackers add to the submitted data, and depending on your code building the query will allow sql injection via any hacker supplied field name you use in the query.

[PCHome]

Thank you, that’s quite helpful. As for SQL injection, this will always redirect to a login page and won’t work without valid authentication as it’s used only by me. As for multiple image uploading, I would love to rewrite it to handle that but I’m far too rusty and it’s not really mandatory. However, I suspect I can simply run it in loop to run multiple times if needed. I put in the multiple attribute out of habit.

Still curious about that odd tmp file name, though, when merging the fields.

[phdr]

Due to viruses, cross site scripting, session hijacking, … you cannot ASSUME that data submitted to your site, even if it appears to be coming from a trusted, logged in user, is safe. You must treat all data submitted to your site - $_POST, $_GET, $_FILES, $_COOKIE, and some $_SERVER as though it can be anything and cannot be trusted. Countless web sites have been taken over when programmers make assumptions about external data.

The tmp file name has nothing to do with this code. If you examine $_FILES, you will find that this is what the tmp name is, on your current system.

[PCHome]

As much as I appreciate the security warning, this site is a long way off to going live so I’m not too concerned about it yet. The programming is far more secure than what’s there now which has been live for close to two decades on one site and a decade longer or more on others.

As for the tmp file name, as many times as I view the $_FILES array alone, the tmp file never begins with php but viewing it as a merged array on the same system, it always begins with it. Not that there is anything wrong but it caught my attention and seemed odd.

[phdr]

@PCHome

this time my sites have a function that generates the prepared statement from the array

Doing this ^ from the keys in the post data is what can be exploited. Is your previous code doing this? If no, then this is a new problem.

The suggested method, also uses an array, but it is defined in your code and consists of the expected fields. It cannot be bypassed by anything that comes from the browser. Once you have created this definition, for any application, you can use it to dynamically validate input data, dynamically produce the sql specific code, and dynamically produce the form.

[PCHome]

I don’t know what you mean by this ^ but nothing with the carrot is used anywhere. Typically the expected field names come from the table column names themselves by way of a query. That’s not programmed into this area but can be. This code is not used for any one single images table or form but rather with each having its own requirements (some sites have more than one images table or different names) so needs to be versatile although I can also pass the field names into it as a separate array if necessary.

[reddig.hamburg]

Actually it’s quite normal that the uploaded tmp files start with ‘php’

This reduces the chance of naming conflicts with files from other applications using the same tmp folder.
While php of course checks, if the chosen tmpname is available, the preceeding php will increase chance that it is available (why would another application prefix with php ?) and php doesn’t need to retry chosing different names.

What you get in either array ($_POST or $_FILES) is just metadata and not the file itself.

While you can merge the arrays into a new array, there is no need to do that. You can access either array any time in your script individually.

Please be aware that you then must be careful about your further processing, because the named keys used in the files array could be existing in the post array as well, if someone is posting those.
Then your merge doesn’t generate the expected outcome anymore.
Best case the uploaded will just fail, worst case you are moving a system file that is assumed to be the tmp file, because the path was injected by a bad guy via post data and you kill your box.

Never trust userland data and always expect the unexpected…

Either way, your upload doesn’t know about if or if not you merge the arrays or even change them.
php will just delete the temp file when it still exists at the end of your script, disregarding what had happened to the arrays in the meantime.

So at some point you should move the tmp file to it’s final destination, if you want to accept it.

That’s all about it.
No magic involved;)