4

I uploaded via ftp, then typed in the URL of the script to Safari; Safari downloaded the source!!

This hosting site has never done that before - .php scripts have always executed.

I can't duplicate it. The page loads as php should now.

Maybe I just caught them while some .htaccess setting was changing?

Maybe my debug line ini_set('display_errors','stdout'); allowed this?

There was a 'compilation failed' error on the page.

So now, I gotta change my sloppy ways and write php code like it is exposed to view.

What could possibly have caused this anomaly?

OK, what happened was, I had recently changed the .htaccess file to use a newer version of php. Fine. But I had also downloaded that .htaccess file to my local server. The web address for the local is similar to the site. So.. fumble-fingered, I didn't notice Safari had auto-filled the address with my local site. The local site was trying to run the script with the new version of php which it did not have, so it just delivered the script as a download. Not the best thing to do, I don't think, but at least it wasn't the live server.

So I have mutated the question to 'should I worry' about exposed php. After all, if my local server will deliver the script text under some conditions, might the live server, also?

Bobbi Bennett
  • 143
  • 6
  • Welcome to the site; please accept the traditional +1 as a welcome gift. Thanks for an interesting question, and for explaining it rather well. I've offered a few edits to try to elicit answers rather than discussions; I hope they're value-add. – MCW Dec 12 '12 at 20:00
  • I checked the apache access log, and see just the one get for the php file, presumably the good one where the script worked. The ftp logs update daily on this host (??) so I do not even see my ftp upload. – Bobbi Bennett Dec 12 '12 at 20:25

4 Answers4

6

The real key here is to avoid having significant PHP code in a location where it would be downloaded even by accident.

The ideal scenario would be that the page that your users request is a minimal index page with as little PHP code as possible, who's sole function is to include other PHP scripts that are in a directory outside the web-accessible area.

This best practice will protect you against the kind of accidental lapses in server configuration that appears to have happened in this case.

I know that this doesn't directly answer the question. The direct answer (per the accepted answer) appears to be that it was indeed a temporary lapse. It's somewhat discomforting to think that a lapse like that can occur and completely compromise a site's security, no matter how temporary it was. But they can indeed occur, and as responsible developers/site admins, we need to take steps to mitigate the damage before they happen. We need to understand what could happen if config files are deleted or modified by accident, or if a hacker manages to work around our top layers of security, and we need to build in secondary layers as a safety net so we can limit the damage if (or more likely when) those things happen.

SDC
  • 206
  • 1
  • 2
  • I gotta try that. So, I have a php directory outside of the html root? The script can load it, but apache will not? Good. – Bobbi Bennett Dec 14 '12 at 18:33
  • 1
    @BobbiBennett - yes, as long as PHP has read permissions to the file, it can be included. It doesn't have to be web accessible except for the initial PHP file that is opened by the web server. And and all includes can be stored separately. Most hosting providers will give you a default directory structure that makes it easy to do this. – SDC Dec 18 '12 at 11:00
  • I just noticed my error_log was exposed, too. I fixed that in the .htaccess, but, really, whaa?? – Bobbi Bennett Dec 18 '12 at 22:17
5

Check your server php configuration as explained here.

Make sure you have AddType application/x-httpd-php .php in the httpd.conf file.
Use <?php instead of <?.

Community
  • 1
LLub
  • 1,246
  • 10
  • 21
  • That handler setting -was- recently changed, to AddHandler application/x-httpd-php53s .php this was done by a cpanel script. It seems their default is an older php. All ran find after that change. – Bobbi Bennett Dec 12 '12 at 20:30
  • This is a very nice answer, if the problem was that php files were not running as script. That is not the problem! They have been running correctly all the time, except just this once. – Bobbi Bennett Dec 12 '12 at 20:38
2

The only way that PHP source could be presented to the user is if a server configuration was off. A browser can only get access to the information presented to it by the web server and the web server should be having PHP process a PHP script and returning the result. If the PHP script was sent to the browser, then the server configuration was off. What could have caused this for only one page is anyone's guess, but if there was a recent change to the handler, it could have removed the old handler just prior to putting on the new one and you may have just been lucky with the timing.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • +1 for getting the question right. Your answer is my first working hypothesis for now, the second being that Mac-Safari-Cyberduck(ftp)-FumbleFingers somehow conspired to make it look like a download from Safari. That first hypothesis implies there are times when the server might deliver the script instead of running it, and who knows when those times might be. – Bobbi Bennett Dec 12 '12 at 22:32
  • I am accepting this as the answer. It isn't quite fair to expect a correct guess to my muddled situation, sort of a 'What do I have in my pocket' riddle. But yes, the 'recent change to the handler' was, it wasn't there! – Bobbi Bennett Dec 13 '12 at 07:51
  • @BobbiBennett - yeah, the really weird part is that it was working and then stopped momentarily, but sometimes weird things happen. Most likely the information needed to identify the weird case is gone now anyway. My biggest suggestion is don't worry about it if it doesn't happen again, but do try running random refreshes and see if you can get it to fail again. – AJ Henderson Dec 13 '12 at 14:01
1

This seems to be a problem with your server, not Safari. Some servers will default to sending the PHP file to the browser to be downloaded if they cannot parse the PHP code. If this happened only once, I'd think it is maybe a small bug in your PHP interpreter, but if this is happening very much, I'd recommend updating your PHP, or checking with your host if you are using one.

gggggeg
  • 141
  • 1
  • 'some servers will .. send the php' ?? Really? Wow. But of course, any testing would reveal that. In this case, the wrong server (my localhost) had the .htaccess for the other server. So it couldn't find anything to run the script. – Bobbi Bennett Dec 13 '12 at 07:48