Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #5189 > unrolled thread

Forum displays PHP code, not website

Back to article view | Back to comp.lang.php

Contents

  Forum displays PHP code, not website "P E Schoen" <paul@peschoen.com> - 2012-03-21 20:57 -0400
    Re: Forum displays PHP code, not website Dave Pyles <dave@user.invalid> - 2012-03-21 21:26 -0400
      Re: Forum displays PHP code, not website "P E Schoen" <paul@peschoen.com> - 2012-03-21 23:20 -0400
        Re: Forum displays PHP code, not website "J.O. Aho" <user@example.net> - 2012-03-22 06:46 +0100
        Re: Forum displays PHP code, not website "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-22 10:29 +0100
        Re: Forum displays PHP code, not website Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-22 10:41 +0100
        Re: Forum displays PHP code, not website Tim Streater <timstreater@greenbee.net> - 2012-03-22 11:12 +0000
        Re: Forum displays PHP code, not website The Natural Philosopher <tnp@invalid.invalid> - 2012-03-22 11:30 +0000
        Re: Forum displays PHP code, not website Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-22 20:38 +0100
          Re: Forum displays PHP code, not website "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-22 21:43 +0100
            Re: Forum displays PHP code, not website The Natural Philosopher <tnp@invalid.invalid> - 2012-03-22 21:25 +0000
            Re: Forum displays PHP code, not website Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-22 17:42 -0400
              Re: Forum displays PHP code, not website "P E Schoen" <paul@peschoen.com> - 2012-03-22 22:23 -0400
                Re: Forum displays PHP code, not website Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-22 22:51 -0400
                Re: Forum displays PHP code, not website gordonb.vi9et@burditt.org (Gordon Burditt) - 2012-03-22 23:37 -0500
                  Re: Forum displays PHP code, not website "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-23 18:13 +0100
                    Re: Forum displays PHP code, not website "P E Schoen" <paul@peschoen.com> - 2012-03-23 21:07 -0400
                      Re: Forum displays PHP code, not website Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-24 10:44 +0100
                      Re: Forum displays PHP code, not website Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-24 09:07 -0400
                  Re: Forum displays PHP code, not website Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-24 10:35 +0100
                Re: Forum displays PHP code, not website Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-24 10:24 +0100

Page 1 of 2  [1] 2  Next page →

#5189 — Forum displays PHP code, not website

Last night I wanted to check out a forum http://www.mytractorforum.com/, but 
instead of showing the forum, it displays the PHP code. I thought it was a 
temporary glitch, but it's going on almost 24 hours now. I don't really know 
how to contact them. But I'm wondering what may have happened. Hacked?

Thanks,

Paul 

[toc] | [next] | [standalone]

#5190

P E Schoen wrote:
> Last night I wanted to check out a forum http://www.mytractorforum.com/,
> but instead of showing the forum, it displays the PHP code. I thought it
> was a temporary glitch, but it's going on almost 24 hours now. I don't
> really know how to contact them. But I'm wondering what may have
> happened. Hacked?
>
> Thanks,
>
> Paul
Seems to be working correctly now.
Dave Pyles

[toc] | [prev] | [next] | [standalone]

#5191

"Dave Pyles"  wrote in message news:jkdv3n$s61$1@dont-email.me...

> P E Schoen wrote:
>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>> but instead of showing the forum, it displays the PHP code. I thought it
>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>> really know how to contact them. But I'm wondering what may have
>> happened. Hacked?
>>
>> Thanks,

> Seems to be working correctly now.

I tried again, and still saw the problem, but it was reloading the page from 
the cache. A refresh cleared it up. I still wonder what could have caused 
the source to be displayed. Would this happen if the PHP application on the 
server was missing or defective?

Thanks,

Paul 

[toc] | [prev] | [next] | [standalone]

#5192

P E Schoen wrote:
> "Dave Pyles" wrote in message news:jkdv3n$s61$1@dont-email.me...
>
>> P E Schoen wrote:
>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>> but instead of showing the forum, it displays the PHP code. I thought it
>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>> really know how to contact them. But I'm wondering what may have
>>> happened. Hacked?
>
>> Seems to be working correctly now.
>
> I tried again, and still saw the problem, but it was reloading the page from
> the cache. A refresh cleared it up. I still wonder what could have caused the
> source to be displayed. Would this happen if the PHP application on the server
> was missing or defective?

This can happen when you upgrade the web server service, like apache or iis 
and you manage to reset or overwrite configurations so that the php module 
isn't loaded anymore, then the php pages will not be parsed and those you get 
the source instead of the result.


-- 

   //Aho

[toc] | [prev] | [next] | [standalone]

#5193

Am 22.03.2012 04:20, schrieb P E Schoen:
> "Dave Pyles"  wrote in message news:jkdv3n$s61$1@dont-email.me...
> 
>> P E Schoen wrote:
>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>> but instead of showing the forum, it displays the PHP code. I thought it
>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>> really know how to contact them. But I'm wondering what may have
>>> happened. Hacked?
>>>
>>> Thanks,
> 
>> Seems to be working correctly now.
> 
> I tried again, and still saw the problem, but it was reloading the page from the
> cache. A refresh cleared it up. I still wonder what could have caused the source to
> be displayed. Would this happen if the PHP application on the server was missing or
> defective?
> 
> Thanks,
> 
> Paul

Even with a correctly installed and "working" PHP the web server will show you the
source code if (Apache on Ubuntu) file /etc/apache2/mods-available/php5.conf is not
linked into mods-enabled/!

php5.conf:
<IfModule mod_php5.c>
    <FilesMatch "\.ph(p3?|tml)$">
        SetHandler application/x-httpd-php
    </FilesMatch>
    <FilesMatch "\.phps$">
        SetHandler application/x-httpd-php-source
    </FilesMatch>
    # To re-enable php in user directories comment the following lines
    # (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
    # prevents .htaccess files from disabling it.
    <IfModule mod_userdir.c>
        <Directory /home/*/public_html>
            php_admin_value engine Off
        </Directory>
    </IfModule>
</IfModule>

/Str.

[toc] | [prev] | [next] | [standalone]

#5194

On 3/22/2012 4:20 AM, P E Schoen wrote:
> "Dave Pyles" wrote in message news:jkdv3n$s61$1@dont-email.me...
>
>> P E Schoen wrote:
>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>> but instead of showing the forum, it displays the PHP code. I thought it
>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>> really know how to contact them. But I'm wondering what may have
>>> happened. Hacked?
>>>
>>> Thanks,
>
>> Seems to be working correctly now.
>
> I tried again, and still saw the problem, but it was reloading the page
> from the cache. A refresh cleared it up. I still wonder what could have
> caused the source to be displayed. Would this happen if the PHP
> application on the server was missing or defective?
>
> Thanks,
>
> Paul

Hi Paul,

The annoying thing that just happened to you also nicely demonstrates 
why you should store your database credentials OUTSIDE the webroot.
I hope you did!

A simple guess like requesting any of the following might reveal the 
right connectstring:
/db.php
/database.php
/connect.php
etc.

Or when the attacker knows you run, for example, CodeIgniter, they can 
"guess" the right place where to find it (application/config/database.php).

(Please note that leaking the connectstring doesn't mean that an 
attacker can access the database over TCP/IP, but it is better avoided 
to leak it anyway. I set up my postgresql without tcp/ip connecting for 
that reason, only local access via Unix Domain sockets.)

Regards,
Erwin Moller

PS: Make sure you complain about this at your ISP!



-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#5195

In article <jke5pr$ovd$1@dont-email.me>,
 "P E Schoen" <paul@peschoen.com> wrote:

> "Dave Pyles"  wrote in message news:jkdv3n$s61$1@dont-email.me...
> 
> > P E Schoen wrote:
> >> Last night I wanted to check out a forum http://www.mytractorforum.com/,
> >> but instead of showing the forum, it displays the PHP code. I thought it
> >> was a temporary glitch, but it's going on almost 24 hours now. I don't
> >> really know how to contact them. But I'm wondering what may have
> >> happened. Hacked?

> > Seems to be working correctly now.
> 
> I tried again, and still saw the problem, but it was reloading the page from 
> the cache. A refresh cleared it up. I still wonder what could have caused 
> the source to be displayed. Would this happen if the PHP application on the 
> server was missing or defective?

No, it's the apache config that needs correcting.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#5196

P E Schoen wrote:
> "Dave Pyles"  wrote in message news:jkdv3n$s61$1@dont-email.me...
> 
>> P E Schoen wrote:
>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>> but instead of showing the forum, it displays the PHP code. I thought it
>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>> really know how to contact them. But I'm wondering what may have
>>> happened. Hacked?
>>>
>>> Thanks,
> 
>> Seems to be working correctly now.
> 
> I tried again, and still saw the problem, but it was reloading the page 
> from the cache. A refresh cleared it up. I still wonder what could have 
> caused the source to be displayed. Would this happen if the PHP 
> application on the server was missing or defective?
> 

More like the web server loaded up misconfigured..

Of it not set to 'recognise' php as something its needs to 'pass off' to 
a php interpreter, code is what comes out..


> Thanks,
> 
> Paul


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#5197

P E Schoen wrote:

> "Dave Pyles"  wrote:
>> P E Schoen wrote:
>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>> but instead of showing the forum, it displays the PHP code. I thought it
>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>> really know how to contact them.

Try WHOIS.

>>> But I'm wondering what may have happened. Hacked?
>>> Thanks,
>> Seems to be working correctly now.
> 
> I tried again, and still saw the problem, but it was reloading the page
> from the cache. A refresh cleared it up. I still wonder what could have
> caused the source to be displayed. Would this happen if the PHP
> application on the server was missing or defective?

Yes.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#5198

Am 22.03.2012 20:38, schrieb Thomas 'PointedEars' Lahn:
> P E Schoen wrote:
> 
>> "Dave Pyles"  wrote:
>>> P E Schoen wrote:
>>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>>> but instead of showing the forum, it displays the PHP code. I thought it
>>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>>> really know how to contact them.
> 
> Try WHOIS.
> 
>>>> But I'm wondering what may have happened. Hacked?
>>>> Thanks,
>>> Seems to be working correctly now.
>>
>> I tried again, and still saw the problem, but it was reloading the page
>> from the cache. A refresh cleared it up. I still wonder what could have
>> caused the source to be displayed. Would this happen if the PHP
>> application on the server was missing or defective?
> 
> Yes.
> 
> 
> PointedEars

Hmm - shure? He said "PHP application on the server was missing or defective?".

Missing not, the code was displayed. Defective? Only when the application printed out
PHP code - well, unlikely, but not impossible.

/Str.

[toc] | [prev] | [next] | [standalone]

#5199

M. Strobel wrote:
> Am 22.03.2012 20:38, schrieb Thomas 'PointedEars' Lahn:
>> P E Schoen wrote:
>>
>>> "Dave Pyles"  wrote:
>>>> P E Schoen wrote:
>>>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>>>> but instead of showing the forum, it displays the PHP code. I thought it
>>>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>>>> really know how to contact them.
>> Try WHOIS.
>>
>>>>> But I'm wondering what may have happened. Hacked?
>>>>> Thanks,
>>>> Seems to be working correctly now.
>>> I tried again, and still saw the problem, but it was reloading the page
>>> from the cache. A refresh cleared it up. I still wonder what could have
>>> caused the source to be displayed. Would this happen if the PHP
>>> application on the server was missing or defective?
>> Yes.
>>
>>
>> PointedEars
> 
> Hmm - shure? He said "PHP application on the server was missing or defective?".
> 
> Missing not, the code was displayed. 

irrelevant.

The application is the web server. That wasn't missing.
The web server didn't give an error. Ergo whether the php worked or not 
or was missing was never an issue.

The issue was that the web server considered the .php file to be a 
simple text page to send.

Misconfigured web server.

Defective? Only when the application printed out
> PHP code - well, unlikely, but not impossible.
> 
> /Str.


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#5200

On 3/22/2012 4:43 PM, M. Strobel wrote:
> Am 22.03.2012 20:38, schrieb Thomas 'PointedEars' Lahn:
>> P E Schoen wrote:
>>
>>> "Dave Pyles"  wrote:
>>>> P E Schoen wrote:
>>>>> Last night I wanted to check out a forum http://www.mytractorforum.com/,
>>>>> but instead of showing the forum, it displays the PHP code. I thought it
>>>>> was a temporary glitch, but it's going on almost 24 hours now. I don't
>>>>> really know how to contact them.
>>
>> Try WHOIS.
>>
>>>>> But I'm wondering what may have happened. Hacked?
>>>>> Thanks,
>>>> Seems to be working correctly now.
>>>
>>> I tried again, and still saw the problem, but it was reloading the page
>>> from the cache. A refresh cleared it up. I still wonder what could have
>>> caused the source to be displayed. Would this happen if the PHP
>>> application on the server was missing or defective?
>>
>> Yes.
>>
>>
>> PointedEars
>
> Hmm - shure? He said "PHP application on the server was missing or defective?".
>
> Missing not, the code was displayed. Defective? Only when the application printed out
> PHP code - well, unlikely, but not impossible.
>
> /Str.

Yes, it could be an application problem.  For instance, using 
short_open_tags in the code and an update to the server disabled them.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#5201

"Jerry Stuckle"  wrote in message news:jkg6cn$mjd$1@dont-email.me...

> On 3/22/2012 4:43 PM, M. Strobel wrote:

>> Hmm - shure? He said "PHP application on the server was missing or 
>> defective?".
>
>> Missing not, the code was displayed. Defective? Only when the application
>> printed out PHP code - well, unlikely, but not impossible.

> 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. When I have had configuration problems, generally 
I have gotten an error message or not even that. What I have is not very 
sensitive or critical but I do have some concerns because I don't really 
know this stuff well enough for full confidence.

Just yesterday I had problems with email on my Dreamhost server, and I 
noticed that the logs seemed to be missing and not updated since last 
August. But apparently there was a change which now requires SFTP / SSH. I 
downloaded and installed WinSCP per Dreamhost's recommendation but found 
that I can also use FileZilla, so I'll stick with that.

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?
http://www.muttleydog.com/RandomQuoteImage.php

Thanks,

Paul 

[toc] | [prev] | [next] | [standalone]

#5202

On 3/22/2012 10:23 PM, P E Schoen wrote:
> "Jerry Stuckle" wrote in message news:jkg6cn$mjd$1@dont-email.me...
>
>> On 3/22/2012 4:43 PM, M. Strobel wrote:
>
>>> Hmm - shure? He said "PHP application on the server was missing or
>>> defective?".
>>
>>> Missing not, the code was displayed. Defective? Only when the
>>> application
>>> printed out PHP code - well, unlikely, but not impossible.
>
>> 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. When I have had configuration
> problems, generally I have gotten an error message or not even that.
> What I have is not very sensitive or critical but I do have some
> concerns because I don't really know this stuff well enough for full
> confidence.
>

But having the passwords in files which are publicly accessible is very 
dangerous - as you have seen.  And just because it's never happened to 
you before doesn't mean it can't and won't.  It might even be tomorrow.

> Just yesterday I had problems with email on my Dreamhost server, and I
> noticed that the logs seemed to be missing and not updated since last
> August. But apparently there was a change which now requires SFTP / SSH.
> I downloaded and installed WinSCP per Dreamhost's recommendation but
> found that I can also use FileZilla, so I'll stick with that.
>
> 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?
> http://www.muttleydog.com/RandomQuoteImage.php
>
> Thanks,
>
> Paul

PHP scripts are not executable files (unless they are CLI and start out 
with a shebang) and should not be set as executable.

And yes, a problem similar to what you saw will expose your code.  The 
webserver can (and has to be able to) read it so a misconfiguration will 
make it visible.

You really need to study up on security and basic Unix administration. 
There are already too many PHP sites with poor security (like one I'm 
working on right now).

Working on the web is like playing with dynamite.  You can be OK for a 
long time, but eventually a cap could explode and blow your hand off (or 
worse).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#5203

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

[toc] | [prev] | [next] | [standalone]

#5205

Am 23.03.2012 05:37, schrieb Gordon Burditt:
>>>> 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.
> 
You say *PHP is* the application, the philosopher said the web server is the application.

I find both statements technically speaking true, but when the OP asked if the
problem was the application he was talking quite clearly about the forum software,
i.e. the *PHP script*.

Agreed that the main executable is the web server, which calls the PHP module. But
when you say "I write my application in python/perl/php" you are writing a script,
not an interpreter!

/Str.

[toc] | [prev] | [next] | [standalone]

#5206

"M. Strobel"  wrote in message news:9t3paiFdoeU1@mid.uni-berlin.de...

Am 23.03.2012 05:37, schrieb Gordon Burditt:
>
>> 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.
>
> You say *PHP is* the application, the philosopher said the web server
> is the application.

> I find both statements technically speaking true, but when the OP asked if 
> the
> problem was the application he was talking quite clearly about the forum 
> software,
> i.e. the *PHP script*.

Actually, I meant the PHP module, which to me is an application, rather than 
a script. And the problem I saw was on someone else's forum, and I did not 
really mean the forum software was the problem. But I'm glad I asked, and I 
can see that I need to learn more about this stuff before doing anything 
really important. What I have now is mostly as a learning exercise.

> Agreed that the main executable is the web server, which calls the PHP 
> module. But
> when you say "I write my application in python/perl/php" you are writing a 
> script,
> not an interpreter!

I think "applications" should be anything that has been compiled separately 
and resides on the server or local machine as an executable. The OS would 
also be an application, but I would refer to it more as an operating system. 
A user shell that accesses the OS would be an application, which could be as 
a terminal (like MSDOS command shell), or a GUI.

Thanks for the detailed information and advice. I think I understand most of 
it. I guess I need to know the extent of the risks involved. As long as the 
site is not in danger of being hacked, I'm not too worried. But maybe I just 
don't know that many ways that a malicious attack could be made.

Paul 

[toc] | [prev] | [next] | [standalone]

#5211

P E Schoen wrote:

> "M. Strobel"  wrote in message news:9t3paiFdoeU1@mid.uni-berlin.de...
> Am 23.03.2012 05:37, schrieb Gordon Burditt:
>>> 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.
>> You say *PHP is* the application, the philosopher said the web server
>> is the application.
> 
>> I find both statements technically speaking true, but when the OP asked
>> if the problem was the application he was talking quite clearly about the
>> forum software, i.e. the *PHP script*.
> 
> Actually, I meant the PHP module, which to me is an application, rather
> than a script. […]
> 
>> Agreed that the main executable is the web server, which calls the PHP
>> module. But when you say "I write my application in python/perl/php" you
>> are writing a script, not an interpreter!
> 
> I think "applications" should be anything that has been compiled
> separately and resides on the server or local machine as an executable.
> The OS would also be an application,

No, an operating system usually consists of a kernel (its core component) 
and a collection of applications that use kernel functions.

> but I would refer to it more as an operating system. A user shell that
> accesses the OS would be an application, which could be as a terminal
> (like MSDOS command shell), or a GUI.

Your definition of "application" is uncommon at best, probably outdated or 
ill-informed.  With PHP 4+ – where source code is JIT-compiled to bytecode 
which is processed by the Zend2 engine (a virtual machine) – one would 
usually develop web *applications*.  I have been and I am employed as "Web 
application developer".


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#5217

On 3/23/2012 9:07 PM, P E Schoen wrote:
> "M. Strobel" wrote in message news:9t3paiFdoeU1@mid.uni-berlin.de...
>
> Am 23.03.2012 05:37, schrieb Gordon Burditt:
>>
>>> 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.
>>
>> You say *PHP is* the application, the philosopher said the web server
>> is the application.
>
>> I find both statements technically speaking true, but when the OP
>> asked if the
>> problem was the application he was talking quite clearly about the
>> forum software,
>> i.e. the *PHP script*.
>
> Actually, I meant the PHP module, which to me is an application, rather
> than a script. And the problem I saw was on someone else's forum, and I
> did not really mean the forum software was the problem. But I'm glad I
> asked, and I can see that I need to learn more about this stuff before
> doing anything really important. What I have now is mostly as a learning
> exercise.
>
>> Agreed that the main executable is the web server, which calls the PHP
>> module. But
>> when you say "I write my application in python/perl/php" you are
>> writing a script,
>> not an interpreter!
>
> I think "applications" should be anything that has been compiled
> separately and resides on the server or local machine as an executable.
> The OS would also be an application, but I would refer to it more as an
> operating system. A user shell that accesses the OS would be an
> application, which could be as a terminal (like MSDOS command shell), or
> a GUI.
>
> Thanks for the detailed information and advice. I think I understand
> most of it. I guess I need to know the extent of the risks involved. As
> long as the site is not in danger of being hacked, I'm not too worried.
> But maybe I just don't know that many ways that a malicious attack could
> be made.
>
> Paul

Applications don't need to be compiled.  Scripts written in languages 
such as BASH, Perl and PHP can also be executables under Linux.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#5212

Gordon Burditt wrote:

> P E Schoen wrote:
>> 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 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.

ACK :)

> [snipped because of Full ACK]
> 
> An additional protection is that the database cannot be connected to
> from the Internet at large, enforced by a firewall.

It is more secure if the database server also does not accept connections 
from outside the server-local network.  This is the default for recent 
versions of MySQL Server (cf. LAMP/WAMP).  Network-local PHP-based 
applications like phpMyAdmin can still access the database then.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web