Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Typically my job description limits me to code-review of web applications. More recently I've been asked to assist with some server-side PHP optimization where, although I am familiar with it, I lack experience.

I have come across a configuration setting called:

disable_functions

Are there any implications I should be aware of by utilizing this setting (other than the obvious function x() will be disabled and any application that uses function x() will then not work)?

If it is something I should be taking advantage of, I can come up with a list of many functions which could be dangerous, however some may be necessary regardless. Does anyone have a list, or have some suggestions to add as far as which functions should be disabled and why in case I miss/overlook some?

Any insight would be appreciated as although I know plenty of unsafe functions, my server configuration experience is lacking.

EDIT: To clear up any question as to whether this is on or off topic, I was asked to assist with OPTIMIZING the PHP enviroment for increased SECURITY, but I'm asking specifically about the aforementioned configuration setting. :)

share|improve this question
    
Is this question about hardening PHP environment or only about disabling dangerous functions? From the beginning of question it looks like you were asked to increase overall security. –  anonymous Dec 29 '10 at 21:01
    
See my edit for clarification –  Purge Dec 30 '10 at 18:24
    
Well, then I would recommend also to edit title of this topic. Securing PHP environment is not only about disabling functions. –  anonymous Dec 30 '10 at 18:49
    
I agree with your last sentence, however I'm not asking how to secure the PHP environment. I'm asking specifically about disabling the functions as a small part of an OVERALL process of securing the PHP environment. –  Purge Dec 30 '10 at 19:17

5 Answers 5

up vote 10 down vote accepted

There are a number of things that must be understood here:

  1. List of dangerous PHP functions is located here: http://php.net/manual . Seriously, almost any PHP function can be dangerous given the right context. strlen and like are probably safe, but any function that talks to outside world can brings surprises if the rest of the code is not safe.
  2. If you want to secure the site, the security should be throughout the code, just disabling some function here and there is not going to work, only going to blind you and lead to sloppy coding.
  3. There are capabilities in PHP that can assist you in writing more secure code, however they won't make secure code from insecure one. Look for open_basedir and allow_url_fopen as an example.
  4. You can use disable_functions to prohibit some actions that you consider dangerous, however only certain classes of actions can be inhibited this way. For example, you can disable exec,shell_exec,popen,passthru,proc_open,system,pcntl_exec and this probably will prevent running external programs from your code - but most of the things done by these programs can be done by PHP means too. And trying to avoid things like "writing a file" probably won't work - you should do it via OS permissions, not via PHP. So, define what exactly do you want to prohibit first and then see if it's possible - while keeping in mind it may be impossible.
  5. Read security chapter in the PHP manual. Read some PHP security books. Security is not done by just setting security=On in php.ini, unfortunately.
share|improve this answer
    
Great answer!!! Succinct, especially, point#5 –  Bhavik Shah Jan 23 at 6:54

If you are hosting a website or a web server then there are functions in PHP which can be use to exploit the web site or web server using PHP scripts and using this dangerous function hacker can get complete control over web server upto root level.

The List of Function dangerous in PHP development

"apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode"

How to Disable dangerous functions in PHP

  1. Locate your "php.ini" file.
  2. then find disable_functions=
  3. then add all the above function in disable_functions like

    disable_functions="eval,system"

^^ here i have disabled only 2 function you can disabled any numbers of function by giving list of function to disable_functions="list of function to be disable separated by comma"

If you want to what each above functions exactly mean search the above function here

http://in2.php.net/manual/en/function.system.php

share|improve this answer
3  
"The List of Function dangerous in PHP development" - according to whom? Why? If I thought there was any benefit in disabling some functions (its arguable in some very obscure edge cases - but there's nothing in the original question to indicate these might apply) the list I'd come up with would look nothing like this. –  symcbean Dec 30 '10 at 10:28
    
Note that disabling eval will break some existing software. It's better to leave it enabled, unless you like explaining to users why application X won't work on your server, but will work on everyone elses. –  devicenull Dec 30 '10 at 14:00
1  
First of all, eval() can't be disabled in such way, it is a language construct, not function. It can be disabled via Suhosin. Secondly, where did you get something like "inject_code"? What's that? Thirdly, why to disable escape[...]? Moreover, this list is not enough - how about sockets, dl(), others? –  anonymous Dec 30 '10 at 14:15
    
IMHO this is an exercise in futility. If somebody gains access to your system allowing him to run arbitrary PHP code on your system, disabling functions not going to help. There are dozens on functions not listed which can be used this way. Actually, this list makes zero sense - mysql_pconnect is there but mysql_connect and mysqli_connect are not. –  StasM Dec 31 '10 at 0:26
1  
About this list of functions, and why I downvote: lucb1e.com/?p=post&id=86 –  Luc Aug 10 '12 at 18:00

The only issues you have to worry about with this is disabling functions that are actually necessary. Disabling functions can definitely help prevent abuse. There are indeed functions such as exec, shell_exec, etc that should almost never be used in a shared hosting environment.

Rather then just relying on this function though, you should consider working on general security. For example, if you use suPHP or similar, you can prevent a whole bunch of attacks, and make securing things a bit easier. Disabling functions should be the last thing you worry about, your server should be secure before you worry about that.

share|improve this answer

There are no inherently dangerous functions in PHP. OTOH it's remarkably easy to write very insecure programs just using the core functionality of PHP. IMHO, 'disable_function' is a placebo for people who can't/won't secure their systems properly.

Don't get me wrong - as a sys admin there are lots of other things you should be doing to secure your server - like setting open_basedir wherever possible, enforcing a strong permissions model, keeping include paths outside of the document root (or with direct HTTP access disabled fro those dirs) and lots more.

I've been asked to assist with some server-side PHP optimization

Are we talking about optimization or security here?

share|improve this answer
    
See my edit for clarification –  Purge Dec 30 '10 at 18:24

While I haven't touched PHP in quite a few years, from what I've read

disable_functions

is most appropriate for shared hosting situations.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.