| Re: Forum displays PHP code, not website [message #177385 is a reply to message #177383] |
Fri, 23 March 2012 04:37   |
gordonb.vi9et
Messages: 1
Registered: March 2012
Karma:
|
Junior Member |
|
|
>>> Hmm - shure? He said "PHP application on the server was missing or
>>> defective?".
>>
>>> Missing not, the code was displayed.
If PHP itself is missing, not turned on, or incorrectly configured,
you can get that result. I take it here that "PHP application"
refers to PHP *as* an application, not an application that *runs*
under PHP.
>>> Defective? Only when the application
>>> printed out PHP code - well, unlikely, but not impossible.
If PHP has problems with loading shared libraries it requires, PHP
can fail and Apache will act like it's not there. It might be a
good idea to shut off Apache while upgrading libraries such as php5,
pcre, libxml2, etc. These libraries may be briefly unavailable
(e.g. a couple of seconds) while they are being installed. You
have to restart Apache after you re-install PHP or libraries PHP
uses anyway. Also, watch apache start up carefully the first time
after the upgrade.
There will be an error message logged somewhere, but if a user
browses to a web page and gets PHP source, they'll get the source
with no error message visible to the user.
There can also be problems with library conflicts. Briefly, this
means that part of PHP or what it loads wants one version of a
library, and other parts of PHP or what it loads wants a different
version of the *same* library. The linker (run-time or link-time)
may give a warning which is easy to miss. This is usually caused
by upgrading a library and rebuilding *SOME BUT NOT ALL* of the
libraries that use that library. This can cause no problems (besides
excessive memory use of 2 copies of the library), subtle problems,
or pretty much complete failure. Complete failure tends to look
like PHP isn't there at all.
>> Yes, it could be an application problem. For instance, using
>> short_open_tags in the code and an update to the server disabled them.
>
> Well, it seems fine now, and it's not my server. Thanks for the variety of
> comments. I do have a few PHP pages on my websites, and I think they are
> well protected enough that the server would never display the code - at
> least I hope so, because I have passwords hard coded in them. They are in
> directories which have permissions set to 711, so the contents should never
> be readable by the public.
Mode 711 on a directory means that everyone (e.g. with a shell
account) can read what's in it (assuming individual file permissions
allow it) if they can guess the file names. It also means that if
it's in the document root, it can be processed by the web server.
As protection, this is a joke. OS permissions just aren't intended
for dealing with access from another system.
> I have a php file for which I have set permissions 711. If the PHP
> executable or the configuration had problems, would the source be visible?
Putting execute permission on a *FILE* in the document tree which
is not a CGI is not a good idea. Don't put excess permissions on
files.
The source could possibly be visible. Most configuration goof-ups
won't cause that. Ones that make Apache think PHP isn't even there
(e.g. missing libphp5.so) could. A missing line like
AddType application/x-httpd-php .php
in httpd.conf could make all your .php files show as source code
(while all the .phtml, .php4, and .php3 files might still work).
> http://www.muttleydog.com/RandomQuoteImage.php
Using OS file permissions and ownership, can Apache/PHP read it?
(Apache has a specific OS user it runs as, typically something like
httpd, apache, or www. Hopefully *not* root).
- If the answer is YES, and if it's under the document root, then
a malfunction in your Apache configuration means it could get
served to browsers as text.
- If the answer is YES, and it's not under the document root, then
it should be safe, given no other malfunctions, like a password-free
shell account.
- If the answer is NO, then Apache/PHP can't read it, and therefore
can't use it, and unless it's good for something unrelated to
Apache/PHP, things would probably be more secure if you just
DELETE it.
I have a set of include files over in /usr/local/share/php. (This
is a default directory for the include file search path - the
location may vary on your system.) Each one defines 4 variables:
$mysql_host, $mysql_user, $mysql_password, and $mysql_db
which are database credentials. Why is there a *SET* of them?
Because I limit groups of PHP scripts to only the permissions they
need, typically one database only, and sometimes read-only, period.
Sometimes there are pairs of them, one for a test database and one
for production.
I recommend the same approach for other types of passwords in PHP
scripts. Keep the passwords OUT of the document tree. If this
is a leased server, you might not have anywhere you can put stuff
besides the document tree.
The relevant PHP scripts require() the appropriate include file.
If PHP is showing source instead of running, the source will show,
including the require directive, which won't be acted upon. If PHP
is running properly, the source will not show and the include file
will be acted upon, but the source of that file won't be listed.
It's safe either way.
An additional protection is that the database cannot be connected to
from the Internet at large, enforced by a firewall.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]