1

I think in a PHP file upload it is a best practice to store files outside of the document root with a randomly generated file name and telling the server to make them non-executable, so the file will not be executed by an attempt to access the file via HTTP.

If storing them outside the root and preventing them from beeing executed at all is not possible in one particular environment, would it help to alter the files extension to one that certainly will not be treated as a script or something similar?

After the upload the actual extension could be saved in a database and the file will be saved in the file system as sd7dsf9gd7s8sd9876asd.secureExtension instead of dangerousScript.php.

Would this be sufficient protection? What extension would be the best one, then?

  • Does the files have to be accessible via HTTP at all? If not, just blocking HTTP requests to the whole folder would solve the problem. – Anders Jan 23 '17 at 16:07
  • I don't have full control over the server and the folder, that is why prohibiting their execution propably isn't possible. – kot Jan 23 '17 at 16:17
  • Changing the extension won't hurt, however it won't stop code execution in combination with other vulnerabilities such as a local file include. – wireghoul Jan 23 '17 at 20:28
0

It will be always possible. For example, if there is a shell script, it doesn't matter how hardly you avoided its execution, a simple sh something will probably execute it.

If it is out of the virtualhost root directory, it is surely a good idea, it closes out the most common attack (uploading something which isn't what it looks, and then tricking the webserver to execute it).

Note: On Unixes, the file extension doesn't mean too much for the OS to determine, what it has to do with it, the OS decides it mainly based on its content. There aren't really even a file extensions (they are simply part of the file name, after the first point).

If you want to make sure:

  • First, don't use "negative lists", i.e. don't specify what "shouldn't be done". By default, everything should be forbidden. Have a - short - positive list, what "could be a done".
  • To apply this conception, I think the best idea if you examine the contents of the files. For example, if you know that they should be pictures, then check their content, and allow only png, jpeg, ...etc files.
  • In the case of HTTP-based file upload, you could also insert constraints to the mime type of the uploaded files, but don't forget: it is set by the client side, i.e. they can say an application/png mime type, while it is essentially a php script.

If an uploaded content doesn't match your short list of the allowed file types, then give an at least partially misleading error message to the user (for example, "upload not allowed" or similar), and initiate a security alarm.

  • Thanks for the reply. I already do a whitelist check for mimetypes. However I think these checks can never be trusted 100%, so if a user manages to upload a potentially dangerous script it simply shouldn't be executable. I also added an update to my question to clarify the type of 'execution'. – kot Jan 23 '17 at 15:43
  • @kot The client can say any mime type, so you can't trust it. But you can constraint the file content based on the said mime type, and you can also constrain the allowed mime types. – peterh Jan 23 '17 at 16:31
1

If your webserver is configured properly (ie it will not execute files with arbitrary extensions as PHP files) this approach will work against PHP code execution*.

Checking/changing extensions is also the correct approach (next to storing the files outside the web root). Checking mime types is unreliable, complex, and may be bypassed by an attacker.

You should use a non-existing extension or one that has no meaning in the given context (ie not .js, .html, .php, etc). Often, no extension is used.

* At least by directly visiting the file; the code can still be executed if the file is for example included and executed somewhere else

  • I'm uncertain if the execution is a matter of proper confiugration. I've seen an article about .jpg files executing php code in their file comment added by gimp upon beeing requested in an internet browser. – kot Jan 23 '17 at 16:10
  • @kot right, but that is a misconfiguration of the webserver (eg via addhandler in apache) or a bug in the webserver (eg if it interprets .php.jpg as php file). – tim Jan 23 '17 at 16:43

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.