PHP security

[JVC]

I just saw in the Bugtraq list that there was an advisory for ASP and PHP scripts that include files from within the www directory.[nbsp][nbsp]In PHP it's pretty standard practice to name your include files with a ".inc" extention and use include("whatever.inc"); in your script.

What I didn't realize is that you can request the include file by itself (http://whatever.com/nav.inc) and the raw file is sent to the browser with out being parsed. :(

Until I can reorganize (rename) my include files to .php3, I've added this to my .htaccess file so no one can peek at my scripts:

<Files ~ &quot;\.inc$&quot;>
Order allow,deny
Deny from all
</Files>

Thought I'd share the info...

[Terra]

Thanks for the Tip...

I will add this into the FQuest core by default... :)

Changes will take effect after tonights STATS run..

--
Terra
--A fresh hosting perspective built from the minds of many--
FutureQuest

[Shalazar]

Thanks for pointing that info out JVC, and thanks to Terra for implementing it so quickly.[nbsp][nbsp]Kudos for making our sites that much more secure :)

[JVC]

Thanks Terra, I still can't get over how quickly FQ responds to *any* issue that arises.[nbsp][nbsp]Keep up the good work!

You guys ROCK! :)

[Terra]

Initial testing had showed the new directive to be safe, but in effect has broken all SSI includes...

Apache should have tunneled the includes without being restricted by the <FilesMatch>, but as I see now - this is now erroring...

The core is being reworked for <LocationMatch> instead of denying at the file level...

This problem should be resolved within the next 30 minutes...

--
Terra
--I feel like I'm playing 'Whack the Mole' right now--
FutureQuest

[Terra]

After further testing, the only choice I have at the moment is to remove the '.inc' protection...

SSI is throwing 9 kinds of monkey wrenchs into this protection scheme... :(

I will be digging into the SSI code to see if there is a way around this snafu...

IOW: It's on my ToDo list...

--
Terra
--Sometimes shooting from the hip, only nails your foot--
FutureQuest

[Terra]

Okay, this was a perplexing enough problem that it piqued my interest to resolve...

I *could* make it work, except for the few site owners that spoil it for everyone else...

This is what I came up with in it's most _optimal_ form:

SetEnvIf Request_URI &quot;\.shtml$&quot; SSI=1
<FilesMatch &quot;\.inc$&quot;>
[nbsp][nbsp]order deny,allow
[nbsp][nbsp]deny from all
[nbsp][nbsp]allow from env=SSI
</FilesMatch>


This *DOES* work, but the problem is with the site owners that chose to bypass the .shtml extension to signify SSI and instead have added the following to their .htaccess file...
AddHandler server-parsed .html

**I have stated numerous times that using .html as .shtml is a _very_ bad idea, now I can show you proof-positive as to why...[nbsp][nbsp]There is no way to differentiate between a SSI and non-SSI call if '.html' is used...[nbsp][nbsp]This limits my ability to bring forth creative solutions...

Now, I could change my above fix to:
SetEnvIf Request_URI &quot;\.s?html$&quot; SSI=1

But this will add unnecessary overhead as EVERY .html and .shtml call will force an environment variable to be set...[nbsp][nbsp]:(

I cannot justify this expense as over 80% of all calls are for .html files...

Oh well, as it stands now, the '.inc' protection will have to remain under user control via JVC's recommendation and using .htaccess files...

NOTE: You can ONLY use JVC's fix if you are NOT using SSI calls to include '.inc' files...

--
Terra
--Optimization is my artwork, and Apache is my canvas with creative solutions being the paintbrush--
FutureQuest

<EDIT: added code tags>
[This message has been edited by ccTech (edited 02-22-00@06:17 am)]

[Justin]

The above is one reason that I always try to keep includes out of the /www/ directory, and I try to use .php for them - this way they are at least parsed and show no output.

One suggestion might be to add the .inc extention to be parsed by PHP - though that raises a concern with including them as SSI's (they'd be parsed for PHP as well)... so that brings about the same issues as 'Deny' directive...

I will admit that on one of my sites, I used a .inc file, right in the doc root, complete with MySQL password visible from the browser if you knew the name of the file - I of course fixed this (plus it's on a password protected site), but it took me by surprise to realize that despite my above suggestions, I also have been guilty...

I hate when I start to post and it becomes a 'thinking out loud' post :) Anyway, hope this helps.

------------------
Justin Nelson
FutureQuest (http://www.FutureQuest.net/index.php) Support

[pier]

I *could* make it work, except for the few site owners that spoil it for everyone else...

Oops, I guess I'm one of them...

Although I added the AddHandler to my .htaccess, I'm using .htm for the few non-SSI html-files.

Guilty,
[nbsp][nbsp]Pier
[ Every (well, for 99.5% sure) .html file I have is using SSI. ]

[JVC]

Ouch![nbsp][nbsp]That got out of hand quickly.[nbsp][nbsp]I didn't mean to double your work load. :(

How about this:

AddType application/x-httpd-php3 .inc

Are folks using '.inc' files for anything other than php3?[nbsp][nbsp]If not, this should be OK and php should only parse them if the '.inc' file is asked for *specifically* from a browser.

Or am I wrong here?[nbsp][nbsp]I haven't fiddled with SSI that much.

I just read Justin's post again...

<<feeling guilty>>


[This message has been edited by JVC (edited 02-22-00@11:45 am)]