I have a client who first asked to enable SSI parsing for .html files. As
this adds extra burden on the server I have it disabled by default. After
some reluctance I gave it to her since she's coming from a server where
she had this all configured herself and needed to rewrite her files if I
didn't cater for that.
Now she's asking for inclusion of php files obviously because she wants
them to get executed and then included in the SSI parsed file. I have
IncludesNoExec set and this is Apache 2.0. As I understand switching this
on is a major security risk. Further, if I understand correctly, inclusion
of PHP files with exec cmd would run them as shell script (if they have
the correct shebang path) which would allow them to break out of any
restrictions the module may have (safe_mode, open_basedir etc.) and
inclusion with exec cgi would only work if PHP was installed as a cgi.
So, I'm very reluctant to allow this. It's a security risk and it adds
extra processing overhead which could all be avoided by just using PHP
from the beginning.
She says she works for several big companies (not our clients) as a
webmaster and claims that including executable PHP in SSI and parsing all
files as SSI is common there to avoid that anyone can see that it's
something else than html files.
I just think it's bad practice.
Am I just paranoid and picky or is this request for inclusion of PHP or
exec cmd in general reasonable?
Thanks for any good advice.

Kai

Kai Schaetzl wrote:
> As I understand switching this
> on is a major security risk. Further, if I understand correctly, inclusion
> of PHP files with exec cmd would run them as shell script (if they have
> the correct shebang path)

Usually, PHP is compiled with --enable-force-cgi-redirect [1] so the
script shouldn't be executed if it's called directly.

> and claims that including executable PHP in SSI and parsing all
> files as SSI is common there

Never heard about that this is a common practice.

> to avoid that anyone can see that it's
> something else than html files.

Well, files with SSI won't have an ETag response-header and without the
x-bit hack no last-modified header, too. So that should indicate that
this is not a static file.

> I just think it's bad practice.

Yes, IMHO thinking about the performance aspect, too. You can easily
send the .html extension through the php praser with

AddHandler handlername .html

Set expose_php to 0 in your php.ini and the requested PHP files should
send the appropriate headers, this includes a process returning a 304
status code if the clients' cache is up to date (checking
If-Modified-Since and If-None-Match request headers).

[1] http://www.php.net/manual/en/securit...e-redirect.php

--
Robert

On Sun, 28 May 2006, Kai Schaetzl wrote:

> I have a client who first asked to enable SSI parsing for .html
> files. As this adds extra burden on the server I have it disabled by
> default.

OK so far, although I prefer "XBitHack full" myself, so that one can
get just a bit (sic of control over cacheability.

Whether SSI is really /needed/ depends on the content, of course. If
it's inserting content that genuinely does change frequently, and
there would be some disadvantage in showing the reader stale data,
then it's OK. If it's used as a lazy way to assemble components into
what is essentially a static web page[1], then it's less justifiable.

> After some reluctance I gave it to her since she's coming from a
> server where she had this all configured herself and needed to
> rewrite her files if I didn't cater for that.

[1] I'm sure I've seen an offline script somewhere which does
SSI-style page assembly, and then publishes the result on the server
as a static file. But I suppose we have to proceed on the assumption
that this page really does need to change per access...

> Now she's asking for inclusion of php files obviously because she
> wants them to get executed and then included in the SSI parsed file.
> I have IncludesNoExec set and this is Apache 2.0. As I understand
> switching this on is a major security risk. Further, if I understand
> correctly, inclusion of PHP files with exec cmd would run them as
> shell script (if they have the correct shebang path) which would
> allow them to break out of any restrictions the module may have
> (safe_mode, open_basedir etc.) and inclusion with exec cgi would
> only work if PHP was installed as a cgi.

This seems to me to be blundering around to a very contorted solution.
PHP has a rather chequered history of security issues, but let's
suppose you have decided you're willing to support PHP on the server.
Then it should be run as a handler directly, *not* executed by some
back-hand mechanism from SSI.

Digression: as I recall, the Apache SSI tutorials recommended, in
preference to #exec cmd="...", to use #include virtual="..." whenever
possible. See e.g the last paragraph of this section
http://httpd.apache.org/docs/2.0/mis..._tips.html#ssi

*But* I'm unclear why one would need SSI *and* PHP together - sounds
like a recipe for unexpected effects, but what's worse, it would rule
out all of PHP's useful features for influencing the HTTP headers.
So I'd do what I could to discourage that i.e re-examine the real
requirement.

> So, I'm very reluctant to allow this. It's a security risk and it
> adds extra processing overhead which could all be avoided by just
> using PHP from the beginning.

Sounds right to me.

> She says she works for several big companies (not our clients) as a
> webmaster and claims that including executable PHP in SSI and
> parsing all files as SSI is common there to avoid that anyone can
> see that it's something else than html files.

Any fool can see from the HTTP response headers that the response from
an SSI is "something else than html files". So this is nonsense.

Don't just look at the filename extension in the URL - as far as HTTP
protocol is concerned, it's meaningless. It doesn't even need to be
there. Or ".html" could signify SSI, or CGI, or PHP or whatever you
care to configure Apache for.

> I just think it's bad practice.

That too, but the whole tangled scheme doesn't seem to make a great
deal of sense. If you/they are going to use PHP at all, then at least
use it properly. Which is what you were saying already.

> Am I just paranoid and picky or is this request for inclusion of PHP
> or exec cmd in general reasonable?

I'd say that in specific instances there might be some justification
for enabling it, but prima facie this request doesn't seem to know
what it wants. Either turn it down, or quote a sufficiently
discouraging extra charge for it, IMHO ;-)

Dislaimer: I happen to run an httpd in an academic situation, as one
of the many other things I'm expected to deal with. But I'd have no
idea what to charge for it commercially, so don't mind me.

cheers