What security risks are there in allowing someone to upload PHP scripts?

Question

Let's say that a partner wants to upload a PHP script to my Apache server. What kind of mayhem could be caused by this?

Which PHP parameters pose threats? If those PHP parameters are fully disabled, would allowing PHP to be inserted on my servers then be safe?

These are some PHP parameters that I know of that pose a security flaw. What others are there that are unsafe?

Writing to server:

1. fwrite

2. file_get_contents

3. FILE_APPEND

Opening files on server:

4. fopen

5. file_get_contents

6. include

7. fread

8. url_get_contents

9. curl_init

10. curl_setopt

Deleting files:

11. unlink
12. unset

Are there any other security flaws that I should be thinking about before allowing partners to add .php files onto my server? I imagine that there might be a lot that I'm unaware of.

I'm also worried about loop scripts that could use up all of my RAM and CPU, backdoor access attacks, malware and the like. Are there any measures that I can take to prevent any of that and more from happening?

If there is Javascript, JQuery or other languages embedded in the PHP script, are those dangerous as well? And what kind of parameters in other languages would I need to disable in order to protect my server?

How do websites like jsfiddle and codepen keep their sites secure while allowing people to post their own code?

Answer 1

It's very dangerous, because you are allowing to someone to upload PHP file with unknown code and unknown intentions, so if you need this functionality as part of your web site, you should harden your server, for example:

• Set a only one directory to upload PHP files from users, you should apply right user permissions (read, write or execution) for this directory, remember create a specific user for this directory, not use root user.
• You can create a .htaccess file for directory, then you could set specific settings for that directory (Configuring .htaccess file).
• Validate input user, even you should set a specific name format and size maximum for PHP files, if a PHP file doesn't match with that format or its size is bigger than what is allowed then application shouldn´t allow to user to upload that file.
• Use canonicalization before use file functions, for example: realpath, basename. This helps you to avoid path traversal attack.

• You should disable PHP functions with high risk, for example: exec, shell_exec. You can do this through php.ini file, for example, you could add the following line helps to disable functions for OS command execution and settings management:

  disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
  

  The following line helps to disable functions for include or open files from external sources:

  allow_url_fopen=Off
  allow_url_include=Off
  

Official documentation php.ini file

Those are some basic recommendations. You should analyze your web application and your needs to set the right settings for your server and web application.

I hope this information helps you.

Answer 2

If you allow somebody to upload and execute a PHP script on your server, you effectively give this person the right to do whatever he or she could do, if she had ssh access with username/password for process the PHP script runs as.

So, if the person in question would run the script through Apache, the person could do anything the Apache user on your server could do.

As an additional risk, this person could use the given access to try privilege escalation, something that would probably break the legal agreement you have with them (you do have a legal agreement, don't you?).

Answer 3

To me it sounds like you are about to shoot yourself in the foot. Letting people you don't trust upload and run PHP on your server is extremely dangerous. Here are some things an attacker could try:

• Run batch commands taking over your webserver. It can then be used as a staging ground to attack other servers from within your network.
• Read files containing secrets, e.g. passwords, encryption keys, TLS keys, etc.
• Do XSS attacks (using JavaScript) to steal session cookies or other credentials from your users. This is assuming the uploaded files run on the same domain or a subdomain as other applications.

The list goes on and on and on. There are ways you could try to block these attacks (hmrojas.p has some suggestions), but that is no simple thing to do. Blacklisting functions is a start, but blacklisting is never more than a partial defense. Even for the best of experts, containing someone who can run PHP is a challenge.

In the end, if you don't trust the person who wrote the code you will have to carefully and manually audit the code to make sure it is benign. That takes time and effort, and it isn't compatible with direct file upload.

Sometimes, the only winning move is not to play. I'd say this is one of these cases.

Answer 4

While there are sites that allow you to run PHP code on demand (i.e. 3v4l), they severely limit what you can do and jump through some major hoops to do it safely

I use a setup where scripts are executed in a small virtual machine. For security reasons this machine has no network and only a minimal filesystem. Scripts are executed by a daemon (written in Golang) and results (with statistics) are reported to a PostgreSQL database. All results are stored and used to provide averages for the performance overview.

I would not allow users to upload PHP scripts in a live environment. We once had an intern who was writing an image upload script. Except he forgot to validate anything about the file he was accepting. Someone uploaded a PHP malware script from Turkey and attempted to take it over (he would have gotten away with it too had it not been for other security efforts on the server).

Answer 5

PHP has a lot of functions to disable features and restrict certain actions so it can be used in shared hosting scenarios. So it is much safer to allow people to upload php scripts than i.e. perl scripts, when your webserver and php instance are configured correctly.

So I want to address another thing than the security of urlopen and similar: You are allowing people to run interactive sites.

The consequences are dangerous independend from how much network or disk IO they can make, because they can for example setup a phishing site, which can reflect badly on your domain and IP reputation.

So you do not end up on a blacklist because of spam mails as they are blocked by disallowing php to send mail, but possibly because you're running a script which phishes for user's facebook logins.

Answer 6

You mention an Apache server, but not whether or not it has PHP installed.

Either piece of software can be used/installed without the other.

Both pieces of software are available for multiple operating systems.. you haven't mentioned which is in play here.

In the case that PHP is installed on the server:

The risk is that, should the user account PHP ends up running under, have administrative rights to the machine, they can do anything in the PHP library.

Should that account not have administrative rights, this restricts what they can do.

Some operating systems have discoverable/known exploits allowing non-administrative accounts to 'get' administrative rights. These are known as privilege escalation exploits. If one is used, then again.. they can do anything in the PHP library.

In the case that PHP is not installed on the server:

There's little to no risk at all. A PHP file is just a text file of instructions that PHP interprets and acts on. It's no more harmful than a text file with a recipe for stew.

Answer 7

There is no way you can “secure” this. Any amount of allowing someone/anyone to execute code at will on a system can lead to complete system takeover, either inherently due to executing all instructions of due to defects in the system that is trying to prevent certain functions from being used.

Even a scripting language in a jail/chroot/container as a dedicated user can ultimately exploit vulnerabilities (existing/new ones) that allows for full root access and more (i.e. firmware access). This is what shared hosting providers have to deal with all day long. Most of the prevention and fixing comes from two things:

1. Legal; list what they can and cannot do in a contract ahead of time

2. Process; have redundancies and recovery schemes in place do deal with breaches/loss

Answer 8

Yeah, you're going to want to sandbox this. Probably the simplest way to do that is with execution in a VM or docker container. Of course, then you'll need to audit the security around that.