php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #14751 [critical!] mozilla downloads source of .php files
Submitted: 2001-12-29 07:57 UTC Modified: 2002-11-11 10:25 UTC
From: info at mkmgmbh dot com Assigned:
Status: Closed Package: Apache related
PHP Version: 4.1.1 OS: redhat 7.1 glibc2.2.4 kernel2.4
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: info at mkmgmbh dot com
New email:
PHP Version: OS:

 

 [2001-12-29 07:57 UTC] info at mkmgmbh dot com 
I don't exactly understand how this happens, but with a Apache+mod_ssl server, Mozilla 0.9.7 is able to retrieve the source of a .php file, probably by sending non-standard headers.

Software used:
- Apache 1.3.22
- mod_ssl 2.8.5
- php 4.1.1
- VirtualHost on port 443 with SSLEngine On.
- "AddHandler application/x-httpd-php .php"

Test URL: https://secure.mkmgmbh.com/horde/test.php

Using Internet Explorer 6, you get the compiled page, using Mozilla 0.9.7 it downloads the source, same url, different behaviour.

Please note that the server uses a non-standard certificate (signed by our own CA).


[Configure line: './configure' '--prefix=/httpd/php' '--with-apxs=/httpd/bin/apxs' '--with-config-file-path=/httpd/conf' '--with-gdbm=/usr' '--with-mysql=/usr' '--with-openssl=/usr' '--with-vpopmail=/home/vpopmail' '--with-gettext' '--with-xml' '--with-mcrypt=/usr' '--with-imap=/projects/serverupd/imap/imap-2001a' '--with-zlib=/usr']

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-12-29 08:35 UTC] info at mkmgmbh dot com 
seems resolved for us.

This phenomenon occurs if the SSL-VirtualHost entry's ServerName differs from the main server's ServerName (in our case nexus.mkmgmbh.com and secure.mkmgmbh.com).

Anyway, this is undocumented _and_ leads to strange behaviour (as posted before, IE seems to have no problems, while Mozilla is able to download PHP-Source-Code in this case, which makes this a definite security-risk for all not-thoroughly tested Internet sites!).

Jonas Maurus
MKM GmbH
 [2001-12-29 13:56 UTC] imajes@php.net 
Since this is not a php bug, (since the behaviour does not
 happen on IE), but does need investigation, I have opened 
a bug on the mozilla bug system:

http://bugzilla.mozilla.org/show_bug.cgi?id=117354

They need a testcase, so if the reporter could recreate the
problem, that would help.

James Cox
 [2002-11-11 06:30 UTC] janus at linux-de dot org 
How can that be?
PHP is a preprocessor, so the files can't be delivered to the browser _before_ php processed them... but it seems that php refuses work...
Another strange issue that teaches us not to use PHP :(
 [2002-11-11 10:25 UTC] rasmus@php.net 
What are you talking about?  This can not possibly be a PHP problem.  It is a web server configuration problem or perhaps a bug in the web server.  What is happening is that PHP is not getting invoked at all because somehow either the server is misconfigured to not apply the PHP mime type in certain circumstances or there is a bug in the server that causes it to lose that mime type.  But the result is that PHP is never getting called.  You can't blame php for that.
 [2002-11-11 10:58 UTC] info at mkmgmbh dot com 
I already told you that it happens when the SSL-Servername differs from the default Servername. I did not, however, reproduce this behaviour again using apache 1.3.27 and php 4.2.3.

This is probably an apache internal communications problem, so that PHP never gets called, or it is a PHP problem, so PHP doesn't get to work. If it is PHP internal I'd guess there's a bug in the EAPI integration, but I'm no expert on that.

When I debugged this stuff there at least was _no_ obvious difference in the http headers sent by Mozilla or Internet Explorer. Nevertheless, Mozilla got the source, *if* and *only if* the SSL-Servername differed from the default server name. The most interesting thing is that IE gets the fully processed page.

Now, this is a very deep technical issue and very hard to debug. If it doesn't turn up again over the next few decades consider it a glitch in the matrix and get over it. This is not the place for "PHP is better than..." and "I think PHP is a security problem" - talks.

Thanks.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Jan 15 11:01:31 2025 UTC