1

When I upload a php file (file.php) with following content on Apache server

<?php
$file = $_GET['file'];
include ( $file);
?>

I am able to read any file of Apache using the below URLs

http://domain.com/file.php?file=/etc/passwd
http://domain.com/file.php?file=/etc/httpd/conf/httpd.conf
http://domain.com/file.php?file=/etc/php.ini
http://domain.com/file.php?file=/etc/my.cnf

I am a Linux user so I know common path of the files, they are almost same on all Linux servers.

I do not have control over what code my developers are uploading. The code review process is full of flaws and this type of code can easily be uploaded on the server. Only thing we can do to forbid it through configuration files.

How can I remove this vulnerability from Apache so no one can read system files even if file.php is there in htdocs?

  • Remove the line "include ( $file);" and your fine Also, thsi is not aan Apache ussie but an PHP one, and read the PHP config documentation on how to limit PHP form actually reading files it should not – LvB Jun 23 '16 at 14:22
  • Possible duplicate of PHP and other files on the server, their visibility and access – LvB Jun 23 '16 at 14:23
  • Yes the code is troublesome so the developers are. Can we prohibit this type of code from config files as well as forbidden executing shell commands through php or cgi (perl) code. Thanks – Derek Jun 24 '16 at 4:50
1

The same "vulnerability" is in C, Java, Perl, Ruby, Lisp, Fortran, BASIC, PASCAL, ALGOL....programming languages almost universally provide a construct for reading files. Some files on a Unix system are world readable.

I do not have control on developers about what code they are uploading...

Then by all means try to mitigate silly mistakes, but don't assume that you can ever make the code safe.

Regarding the specific problem you described....

PHP's open_basedir shuts down a lot of the avenues for reading files (not all of them).

Running PHP in a chroot is a more robust mechanism for restricting file access - but it doesn't prevent access to the PHP code itself.

Running PHP on a separate host will add a little latency - and doesn't really have much advantage over running it chroot.

The right way to fix the problem is through proper code review/audit.

3

This is not a vulnerability in Apache. It is a vulnerability in your PHP code.

The function include(x) includes the file x. If you let the user pick any x, they will be able to include any file. If you don't want them to be able to do that, then don't write PHP code that lets them. I suggest you only pass constants or values from a whitelist as parameters to include().

If you are worried about your developers uploading bad code like this to the server, there is nothing you can do other than getting better developers (educate or replace) or a better review process. A PHP script could in practice be written to do anything the PHP interpreter has priveliges to do, and that is a lot. You could for instance write a backdoor in PHP giving anyone full access to your server.

To repeat, there is no magic config file that will make PHP inherently safe. The only way to keep you server safe is to only upload safe code to it, be it PHP or any other language. You can't get security with the push of a button; you need to integrate the perspective into your entire development process.

0

One way to stop Apache from reading system files (and, in general, any file outside the web root directory) is with SELinux. Its whole purpose is to prevent inappropriate access to system resources (not restricted to constraining Apache, but that sort of protection is one of its great benefits).

You would need to use an operating system that supported it, though, which is probably RHEL and its derivatives (CentOS, for example).

0

You can restrict which directories PHP scripts may access using the open_basedir configuration.

e.g. putting open_basedir = /var/www/ in your php.ini file should restrict PHP to /var/www/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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