User Tools

Site Tools


linux:securingphp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
linux:securingphp [2014/12/24 10:42] – external edit 127.0.0.1linux:securingphp [2018/05/13 19:03] rlunaro
Line 1: Line 1:
 ====== Securing PHP ====== ====== Securing PHP ======
  
-Some years ago I had the personal pleasure of know c99.php: a website of friend of mine got caught by this unpleasant visitor+Here is my configuration / notes about securing a php installation.  
 + 
 + 
 +===== php_openbasedir must be configured per site ===== 
 + 
 +In the apache configuration of the virtual host, **open_basedir** must be configured and must point  
 +to the directory of the web application or deeper, to ban php to open other files that aren't in the  
 +installation 
 + 
 +Example: 
 + 
 +<code> 
 +    <Directory "/mywebsite"> 
 +        php_admin_value open_basedir "/mywebsite:/dev/urandom" 
 +    </Directory> 
 +</code> 
 + 
 +===== include_path must be specified also and limited to the web directory or deeper ===== 
 + 
 +''include_path'' is another funny thing. It specifies what php files can be read by the  
 +''include'' commandit's better to specify the more constrained directory possible: if the  
 +application has an "include" directory, specify this directory only, to avoid an attacker  
 +to read configuration files or other information.  
 + 
 +This configuration must be set per virtual host, and it's better to set non-existent file  
 +in the main php.ini file.  
 + 
 +Example: 
 + 
 +<code> 
 +  php_admin_value include_path "/mywebsite/include/" 
 +</code> 
 + 
 + 
 +===== upload_tmp_dir must be set OUTSIDE YOUR WEBSITE ===== 
 + 
 +**__This is frequent source of problems__**. And I misunderstood that many times, until somebody 
 +kindly let me know about this, by injecting c99.php in my website. This directive configures  
 +the directory where upload files must be placed when loaded: it's a very bad idea to have them  
 +inside your website, because it allows an attacker to upload any php file and execute it afterwards.  
 + 
 +Example:  
 + 
 +<code> 
 +php_admin_value upload_tmp_dir "/tmp" 
 +</code> 
 + 
 + 
 +===== engine must be unset if the site doesn't need php  ===== 
 + 
 +Configure ''engine on'' only if you need php in the virtual host:  
 + 
 +Example:  
 + 
 +<code> 
 +php_admin_value engine On 
 +</code> 
 + 
  
-For those who don't know this script, it is a little piece of art: once uploaded to a website, it allows the attacker to change everything that is changeable and to hack everything that is hackable, if such verb exits. Well, to the point: I am the type of person that thinks that the solution is not to create an automatic to tool to scan the server every X minutes and detect it and delete this type of files. The solution is to put in place the security measures to avoid and minimize the posibility of these scripts to prosper.  
  
-After examining the website, soon we realized that there are ways to avoid an attack of this nature without restricting too much the security of your instalation. Here is a little resume of what we have learned of that days.  
  
  
linux/securingphp.txt · Last modified: 2024/02/05 13:57 by rlunaro