hacking php codes

I am not much of a hacker, but I been thinking of ways people can download or get to codes in my .php files. Since php is parsed server side, I dont see how someone can dl the actual code without somehow hacking my ftp account and dl'in the code.

I know alot of people change .php extension to .whatever to attempt to "hide" their php code, but is that necessary? I cant think of any way for a hacker to get my php code by using IE alone.

Anyone with an insight?

PS. I am not asking anyone to show me bible to hacking php codes because tahts not what I am after. I was just wondering if taking those extra step to secure php such as changing extension is really needed.

they dno'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 the source code unless you let them, or you are running exploitable software that allows them to do so, or they have access to your shell/ftp account.

There is no way to simply "view source" on PHP source.

NOTE: If your web server get's restarted (some how) 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 out of the DOCUMENT ROOT.

ie:

/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.

There is an extremely small chance a sick web server could send a .php file without processing it (I've seen in happen to .asp pages, but never .php). 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 obtained by an HTTP GET request; only by includes in a container .php file that, if the server is sick, ain't gonna run anyways.

There's a bit more to secure PHP programming that protecting your source, and I don't claim to know any of it! Read the documentation and consider a book like Secure PHP Programming (I haven't read it).

Funny, I think we replied at the exact same time.

Yes, my comment 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.

This is an interesting topic. I have expanded apon it in another thread regarding Apache File directives.

http://www.ozzu.com/programming-forum/apache-directives-t21593.html

Axe, actually, they DO change the extension name to protect the file. Its actually a pretty comon practice. You can configure Apache to parse anything as PHP. Some people i know use .inc for include files.

http://www.php.net/manual/en/security.hiding.php have some info regarding using that technique to hide php data.

So I guess in general. Only a "sick" webserve will actually serve up php code in general.

see this for php security info: http://forums.devshed.com/showthread.php?t=20525&page=1

DO NOT rename your .php files .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.

If you intend on changing the .php file extension to hide the PHP installation, you'll also need to set expose_php=Off and display_errors=Off in your php.ini. In addition, ServerSignature Off must be set in httpd.conf.

I dont have access to a folder outsite the web root, so I chmod my php_includes directory to forbid access.

Here is the difinitive answer from one of the phpBB team:

http://www.phpbb.com/kb/article.php?article_id=54

I know I posted this some other place at OZZU -- but it will give you pretty much all the info you need to know.

Assuming your 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.

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 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 head 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 & naming 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, or allow execution of Perl CGI scripts in any directory that Apache has access to, or process SSI directives regardless of whether the file's extensio is .shtml or not. It simply hogs too many resources.

The default for all folders was 755, I chmod'ed a folder to 700. I can't access it by navigating to it: http://www.alpha-matrix-design.co.uk/content/
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!!!