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

A

Anonymous

Guest
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?

Code: 
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?
Click to expand...

phpexploit said:
For stupid people it makes no sense for smart people it makes sense!
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top