1

The php.ini file has an option called disable_functions. You can add unsafe functions to it so that they cannot be run. Does anyone have any guidelines for a good setup with Craft for this. I realize that this is somewhat sort of subjective, but I'm sure there are some features that could without a doubt be turned off that Craft will never use.

OWASP suggests the below settings. Any thoughts on this?

disable_functions = "system, exec, shell_exec, passthru, phpinfo, show_source, popen, proc_open, fopen_with_path, dbmopen, dbase_open, putenv, move_uploaded_file, chdir, mkdir, rmdir, chmod, rename, filepro, filepro_rowcount, filepro_retrieve, posix_mkfifo"

Lindsey D
  • 23,974
  • 5
  • 53
  • 110
Davin Studer
  • 143
  • 5
  • Are you trying to make it more resource efficient or have you experienced (security?) problems with exposed functions in the past? – Matt P Apr 06 '16 at 21:40
  • Trying to harden the server a bit more to lock down potentially unknown security issues. – Davin Studer Apr 06 '16 at 21:49

2 Answers2

3

I'm not aware of a definitive list, but Craft have problems running with some of the methods in your list disabled.

phpinfo, move_uploaded_file, chdir, mkdir, rmdir, chmod, rename

Any plugins you have installed might have additional function requirements as well.

Brad Bell
  • 67,440
  • 6
  • 73
  • 143
3

I don't claim to be a security expert, but I have ran a server for a number of years. Keep in mind that whatever you do, running a public a server on the Internet is always going to put you at some risk, known security issue or not.

You're already making daily filesystem and mysql backups, right?

Just a cursory inspection of that list of functions, you're going to run into problems when Craft uses the filesystem, for example uploading assets, renaming files, etc. You should probably leave out:

move_uploaded_file, chdir, mkdir, rmdir, chmod, rename

The intention there a malicious attacker can't upload a file, move or rename it, and then execute it.

Craft already does an adequate job of filtering out nasty files so they don't get uploaded. If you want to go further, I'd recommend disallowing PHP to actually run code in any of your asset upload directories since those are probably going to be above the web root.

I just did a search of the rest of the functions; phpinfo is used also used the control panel. I don't think that poses as much of a threat. Even if an attacker knows some file system paths, if it he can't write to them, he's DOA.

I'm also a fan of open_basedir. It's a cheap form of "jailing" the web application inside a specific root. I run PHP-FPM which you can setup per pool, per user to make things a little more secure as well.

Community
  • 1
RitterKnight
  • 6,582
  • 14
  • 24