Get PHP source code via Hacking?

GE

genxservers

5 1
Asked
Updated
Viewed
70.5k times

I am not much of a hacker, but I have been thinking of ways people can download or get access to my PHP source code. Since PHP is parsed server side, I don't see how someone can download the actual files without somehow hacking my FTP account and downloading the source code.

I know a lot of people change .php extension to .whatever to attempt to hide their PHP code, but is that necessary? I can't think of any way for a hacker to get my PHP code by using a browser alone.

I am not asking this to learn how to do it myself, I am more wanting to take any extra and/or necessary steps to secure my PHP source code. Does anyone have any insights?

add a comment
1

4 Answers

  • Votes
  • Oldest
  • Latest
AX

Axe

55 1
Answered
Updated

People don't change the .php extension to .whatever because web servers are usually configured to only parse .php files (or .phtml) for PHP commands. If it's called something else, the PHP code doesn't execute.

There is NO way for them to get access to the PHP source code unless:

  1. You let them.
  2. You are running exploitable software that allows them to do so.
  3. They have access to your shell or FTP account.

There is simply no way to view PHP source.

  • 0
    Axe, actually, they DO change the extension name to protect the file. It's actually a pretty common practice. You can configure Apache to parse anything as PHP. Some people I know use .inc for include files. Hiding PHP in the PHP manual has some info regarding using that technique to hide PHP data. It does say that security by obscurity is one of the weakest forms of security, however, every little bit of extra security is desirable. So I guess in general, only a malfunctioning or unhealthy webserver could actually serve up PHP code in general. — genxservers
  • 0
    DO NOT rename your .php files to .inc, you are potentially opening up a HUGE security hole. Many servers WILL show the code inside the .inc if the .inc is requested through GET. Some people use a .htaccess command to stop this, but what if you move to another server and forget to copy the .htaccess file?? I say again, DO NOT rename your PHP files .inc! If you have a script that uses .inc files, change all the .inc files to .php or .inc.php and you will be a lot safer. Not that you MAY have to modify the script. — rjstephens
  • 0
    Yes, Apache can be configured to parse anything for PHP commands, but any serious system admin isn't going to do that. If you have 50 clients on a box, and only one of them uses PHP and the other 49 use straight static HTML, what sense does it make to have those other 49 users bogging down the system, and making their sites run slower by forcing PHP parsing? Most servers that I've experienced online over the last dozen or so years, rarely deviate from the standard extensions for the server-side scripting language. As far as using .inc, most of the scripts I've seen have been .inc.php (for example, config.inc.php). If you include('config.inc'); from a .php file, yes, it's going to include it and execute any PHP commands contained within, but only because it's a .php file that's calling it. If you simply went to http://www.whatever.com/config.inc, then its contents would be displayed right out to the browser (by default). So personally I feel it's a stupid thing to do. Why not use config.inc.php instead of config.inc as thousands of scripts out there already do? 🙂 If you're the only site on the server, and you have root access, then sure, go ahead and totally customize it to do whatever you want. If you're one of many sites on a server, and you only have control over your own home user account, there are a million and one things beyond your control, so you have to design your code and naming conventions with those things in mind. Not every system administrator is going to be willing to have every file that Apache throws out globally parsed for PHP commands, allow execution of Perl CGI scripts in any directory that Apache has access to, or process SSI directives regardless of whether the file's extension is .shtml or not. It simply hogs too many resources. — Axe
  • 0
    Axe, I thought you could set what file types get processed on an individual directory basis - using .htaccess This is from memory, but maybe I am totally wrong. — LazyJim
  • 0
    You can if Apache is configured to allow this kind of control, yeah. — Axe
add a comment
1
LE

_Leo_

20 0
Answered
Updated

If your web server gets restarted (somehow) without the PHP module or configuration, your PHP source code is totally exposed since the webserver will send the PHP file as any other text file to the client.

Of course, it's an exception, but it may actually happen. For that matter, I use to put PHP files having passwords inside directories outside of the DOCUMENT ROOT.

For example:

/myhome/public_html (PHP files here)
/myhome/include_php (sensitive PHP code here (DB password usually))

Of course you have to include the files under /myhome/include_php in order to use them.

  • 0
    There is an extremely small chance an unhealthy web server could send a .php file without processing it, I've seen it happen to .asp pages, but never .php. I agree with Leo, if you have a piece of code that is extremely sensitive, don't save it under the base directory of the web server. Add a directory to the include_path (see PHP.ini) elsewhere on your filesystem. Files stored in that directory cannot be obtained by an HTTP GET request; only by includes in a container .php file that, if the server is broken, is not going to run anyway. There's a bit more to secure PHP programming than protecting your source, and I don't claim to know any of it! Read the documentation and consider a book like Secure PHP Programming. — rjmthezonenet
  • 0
    Yes, my answer was assuming the admin of the web hosting system admin knew what he was doing and the system is fully operational 😉 Of course, you could always try the Zend encoder, and that way, even if you offered your source freely available for download, nobody would be able to read it, heh. But last time I checked, Zend encoder costs about 1500 bucks. — Axe
  • 0
    This is an interesting topic. I have expanded on it in another thread regarding Apache File directives — rjmthezonenet
  • 0
    I don't have access to a folder outside the web root, so I chmod my php_includes directory to forbid access. If someone tries to access that folder they will receive a 403 forbidden error. — LazyJim
  • 0
    Assuming you are talking about read access, that won't work because the web server must read those files. If the web server can, so can a hacker. — rjmthezonenet
  • 0
    The default for all folders was 755, I ran the chmod command to set the folder to 700. I can't access it by navigating to it. But my PHP scripts above that folder can happily include files that live in the protected folder. Please tell me ways that hackers might get past my simple protection! — LazyJim
add a comment
1
RJ

rjmthezonenet

15 0
Answered
Updated

If you intend on changing the .php file extension to hide the PHP installation, you'll also want to make some changes in your php.ini file to help prevent hackers from knowing you are running PHP:

  1. Set expose_php = Off
  2. Set display_errors = Off

In addition, you will also want to change your httpd.conf file, ensuring that you have this set" ServerSignature Off as that could reveal information about how you are serving your content.

add a comment
1
HA

hack24

10 0
Answered
Updated

Another way a potential hacker could get at your PHP source files is if there is a vulnerable script on that server, someone could then exploit it to read your PHP code.

For example:

vuln.php (very simplified)

<?
echo file_get_contents($_GET['thefile']);
?>

Someone could then request this:

vuln.php?thefile=/path/to/your/script.php

and receive the source of your PHP file. While none of your scripts may be vulnerable if you're on a shared server, any of the other sites hosted on that server might be exploitable.

It's unlikely that vuln.php will exist exactly as in the example, but lots of scripts read files, and if the paths to the files are sent via user data (GET, POST, Cookie), then they can be exploited in this way.

Also, if someone is on a shared server, they can sometimes read all the files on the server, eg:

read.php:

<?
echo "<pre>".file_get_contents("/etc/passwd")."</pre>";
?>

works on most servers, also:

<?
echo "<pre>".file_get_contents("/home/vhosts/anothersite/public_html/theirscript.php")."</pre>";
?>

will work on a few badly configured servers.

add a comment
1