Disable dangerous php functions in php.ini to reduce security exploits



Hello greetings I want to disable dangerous php functions in php.ini on Apache webserver with PHP 7.4 to reduce exploits and close some security holes!

I have collected a list from multiple sites that I've found around on the internet to disable dangerous php functions. I have post the whole list below. I want to know what functions are all valid and still working to remove any deprecated or obsolete php functions? Also what php functions can I add that are missing to improve security?

disable_functions = exec,passthru,system,proc_open,popen,curl_exec,curl_multi_exec,show_source,readfile,escapeshellarg,escapeshellcmd,dl,pg_lo_import,dbmopen,dbase_open,chgrp,chown,chmod,symlink,pclose,apache_child_terminate,apache_setenv,apache_getenv,apache_get_modules,apache_get_version,apache_lookup_uri,apache_note,apache_request_headers,apache_reset_timeout,apache_response_headers,define_syslog_variables,proc_open,proc_close,proc_nice,proc_terminate,proc_get_status,eval,fput,ftp_connect,ftp_exec,ftp_get,ftp_login,ftp_nb_fput,ftp_put,ftp_raw,ftp_rawlist,highlight_file,inject_code,openlog,php_uname,phpAds_remoteInfo,phpAds_XmlRpc,phpAds_xmlrpcDecode,phpAds_xmlrpcEncode,syslog,xmlrpc_entity_decode,phpinfo,gzinflate,fsockopen,pfsockopen,getmyuid,getmypid,leak,listen,diskfreespace,tmpfile,link,ignore_user_abordsource,fpaththru,virtual,posix_kill,posix_setpgid,posix_setsid,posix_getpwuid,posix_mkfifo,posix_uname,posix_getcwd,posix_getegid,posix_geteuid,posix_getgid,posix_getgrgid,posix_getgrnam,posix_getgroups,posix_getlogin,posix_getpgid,posix_getpgrp,posix_getpid,posix_getppid,posix_getpwnam,posix_getrlimit,posix_getsid,posix_getuid,posix_isatty,posix_setegid,posix_seteuid,posix_setgid,posix_times,posix_ttyname,posix_ctermid,posix_access,posix_mknod,posix_setp,closelog,debugger_off,debugger_on,define_syslog_var,disk_free_space,ftok,limit,mysql_list_dbs,mysql_pconnect,pg_host,reaink,safe_dir,satty,set_time,socket_accept,socket_bind,socket_clear_errorsocket_close,socket_connect,fput,pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority

I have excluded the php functions in the list below or else they cause conflicts and problems with Matomo analytics. I also use joomla, wordpress+elementor and tiki cms on my webserver. Let me know if some disabled php functions can cause any conflicts in the list above? Thanks for the advice.

shell_exec (required by Matomo!)
ini_set (required by Matomo!)
ini_alter (does matomo or any app I use need this?)
ini_restore (does matomo or any app I use need this?)
ini_get_all (required by Matomo!)
parse_ini_file (required by Matomo!)
parse_ini_string (required by Matomo!)
allow_url_fopen (required by Matomo!)
set_time_limit (required by Matomo!)
scandir (required by some Matomo plugin!)
You want to disable functions that are security risks in PHP? That doesn't make sense.

Simply don't use them
When you disable php functions you don't use you disable certain exploits or else hackers can call up php functions to execute remote exploit code with 0day exploits to hijack your webserver and website.
For stupid people it makes no sense for smart people it makes sense!
This is a decent list. Disabling them outright is likely to cause problems though; it wouldn't surprise me if the PHP applications you're running rely on a few of those functions.

Rather than blindly disabling stuff, you should take the time to understand what code you're running and where the risks are.
phpexploit said:
I have collected a list from multiple sites that I've found around on the internet to disable dangerous php functions. I have post the whole list below. I want to know what functions are all valid and still working to remove any deprecated or obsolete php functions? Also what php functions can I add that are missing to improve security?

phpexploit said:
For stupid people it makes no sense for smart people it makes sense!

I first saw this thread a week or so ago, and I have debated with myself over whether I should remark on it. The thread is a year old and the OP (phpexploit) is just such a blatant troll, while the subject is something that every programmer should be concerned about and the specific topic is something which causes huge confusion.

First off, there is no such thing as "an insecure function" in any programming language. There is only "insecure usage." If the function itself were really insecure then that would be something the platform developers should fix ASAP. Reality is that absolutely any function, built-in or custom-built, which accepts input from remote users and then does literally anything at all with that input, can become "insecure" if the programmer does not take steps in their own code to ensure that it is not. That is exactly the reason why web-forums (just like this one), repositories like Github, and every other type of webservice which accepts user input wants to resort to "markdown" (like [code]Some example[/code]) rather than allowing user-defined "markup" (like <pre>Some example</pre>).

Take Microsoft and their Visual Studio IDE (VS), with its "security warnings" as a perfect example: Since clear back to VS 2008, VS will whine about security risks if you try to use the ANSI C sprintf function. This is just a plain old lie! There is nothing insecure about sprintf which the programmer cannot fix with a simple if/else block. The underlying "risk" has to do with careless or stupid people mis-using sprintf with user-input, where (mostly in much older computer systems with low RAM) a user may input more data than there is available system RAM and then the system crashes at runtime. By simply checking the amount of data in the input stream, cutting the data off at a certain point, or just alerting the user that they input too much, the "security risk" vanishes like a fart in the wind.

So here comes some clown who calls itself "phpexploit" (red flag by itself) blasting the forum with all kinds of worthless data (I refuse to call this nonsense "information"), about what functions are insecure and how or why some pre-baked frameworks demand them.

Absolutely none of phpexploit's listed "insecure functions" are factually insecure, unless they are used by somebody who has no clue what they are doing. If you ever use eval() and allow remote users to input anything they want, without any form of checking to make sure they are not inputting PHP, then you made a mistake and the only security risk is you. The same goes for exec, shell_exec, and so on. What is most telling about this OP's malicious intent is that, while the troll badmouths PHP functions all day long, there is absolutely no mention of other exploitable vectors - particularly SQL injection, such as a user inputting SQL statements into a textarea or inputbox or even into GET parameters in the URL - which is a concern for literally every SQL Engine in existence, which can only be solved by the programmer, and which does not represent any bug or failure or security flaw in any SQL Server at all.

So whether you disable this disinformant's specified functions or not, remote users cannot exploit them unless you make it possible.
Disabling dangerous PHP features is a good security measure, but it's important to carefully consider the potential impact on your application. Some of the features you mentioned are required for specific functionality. Therefore, completely disabling these features may cause conflicts or break the functionality of your application.

Let's take a look at the list we provided and the features we left out.

I said Piwik needs it. Disabling this feature may prevent certain features of Piwik from working properly. Therefore, it is best to keep it enabled when using Piwik. 2.ini_set, ini_alter, ini_restore, ini_get_all:
These functions are used to manipulate PHP configuration settings. Disabling them can affect application configuration and behavior. As such, this is generally not recommended unless there are specific security concerns related to these features.

3. parse_ini_file, parse_ini_string:
These functions are used to parse the INI configuration file. Disabling them may affect the functionality of applications that rely on INI file parsing.

This function is used to enable or disable the ability to open remote files using functions such as file_get_contents or open with a URL. Disabling it prevents access to remote resources, but also increases security by preventing potential vulnerabilities. Consider your application's needs before disabling it.

Five. Set a time limit:
This function sets the maximum script execution time. Disabling this can cause long or infinitely long scripts to run, which can have security implications. Consider the needs of your application and set an appropriate time limit instead of disabling the application entirely.

6. Scandyl:
You said you need it for the Piwik plugin. Disabling this feature may affect the functionality of this plugin or other directory-scanning-based code.

For Joomla, WordPress (using Elementor), and Tiki CMS, please refer to their documentation or support forums to see if any of the disabled features are core functionality or specific plugins or extensions you are using. It's a good idea to check if it's not conflicting with Different applications that have different requirements, so it is important to understand how these features are used in the context of each application.

In general, it's a good idea to test your application thoroughly before disabling PHP features to ensure that your application continues to function properly. Monitor error logs and user feedback to identify potential issues due to disabled features and adjust your configuration accordingly. Finally, keep in mind that disabling features is only one aspect of application security. It is important to implement other security measures as well. B. Input validation, output encoding, parameterized queries for database interaction, and regular security updates of the application and server environment.