Re: Conditional HTML with SSI

[Thomas 'PointedEars' Lahn]

Ben Bacarisse wrote:

> Rhino <no_offline_c...@example.com> writes:
>> On 2014-05-27 11:39 PM, Ed Mullen wrote:
> <snip>
>>> I said to upload it to a protected directory for a reason:
>>>
>>> <http://stackoverflow.com/questions/3196011/what-security-problems-could-come-from-exposing-phpinfo-to-end-users>
>>>
>>> you expose this data at your own peril.
>>
>> Fair enough. Would you care to explain what you mean by a "protected"
>> directory in this context then? How do I protect the directory where I
>> put the phpinfo.php file?
>
> That may be rather over-the-top (but worth doing you already have such a
> thing set up). You can put it up for only as long as it takes to take a
> copy of the output. This is probably safe enough, especially if make it
> "un-guessable". Give the file a name like fd6621c78b399e93c0ae185e.php
> and you will be fine. (Obviously don't use *that* name -- I've just
> made it public!).

There is no such thing as “un-guessable”. For example, an attacker can
easily generate an HTML document or documents with links of permutations of
URIs and have robots like Googlebot add the working URIs to its index. Once
it is indexed, it can be found using the “site:…” filter of Google Search,
for example.

<http://www.googleguide.com/google_works.html>

A simple way to make privileged information inaccessible is to add “.ht” in
front of the resource name when you do not need it, because there is a
default Apache configuration directive that make those resources unavailable
to the world:

,----[/etc/apache2/apache2.conf on Debian GNU/Linux]
|
| […]
|
| #
| # The following lines prevent .htaccess and .htpasswd files from being
| # viewed by Web clients.
| #
| <Files ~ "^\.ht">
| Order allow,deny
| Deny from all
| Satisfy all
| </Files>
|
| […]
`----

They usually do not appear in file listings and accessing such a resource
gives a 403 Forbidden response status code then (test before use). Those
directives are usually in the main configuration files (httpd.conf or
apache2.conf) that reside outside your webspace (on Unices, in the /etc
directory); if an attacker can read or modify those files, you have bigger
problems to worry about than that they could read your PHP version and
configuration. However, the 403 will tell an attacker that such a resource
is there and they may infer that there are times when it is accessible under
the original name.

Another way is to unset permissions of the file, like “chmod o-r
phpinfo.php”. This way an attacker will/should get a 500 Internal Server
Error response with a blank document which could (and should) mean anything.
However, the resouce will be contained in file listings.

Combining the two approaches will still tell the attacker that the file is
there.

By “protected directory” probably a path requiring HTTP Authentication
(easily set up with .htaccess) was meant, but that also can be cracked using
a brute-force attack (just not as easily: you would need to crack the
username and the password). Basic HTTP Authentication should probably not
be used for this, but more elaborate authentication mechanisms may not be
available and then this is better than nothing. Good if you can combine
this with SSL/TLS so that your username and password cannot be easily
sniffed.

That said, a file containing “<?php phpinfo();” (that is all it takes) is so
easily created that one should reconsider whether it is worth the risk of
keeping it at all. I am now thinking of a shell script executable only by
me that creates this file on demand and deletes it when I am done testing in
the browser and hit a key in the shell. Another possibility is to use “php
-c $WEB_CONFIG.php -r 'phpinfo();'” if you have the PHP CLI on the server.

None of that is on-topic here in comp.infosystems.www.authoring.*html*.
X-Post & F'up2 .misc.

It is prudent to consider only PHP-related advice given in
<news:comp.lang.php> and corresponding language-specific or local
newsgroups, with few exceptions.

Web server configuration is on-topic in the
comp.infosystems.www.authoring.servers hierarchy. Apache configuration is
probably best discussed in
<news:comp.infosystems.www.authoring.servers.unix> because Apache is
primarily used on Unices. Otherwise there is
<news:comp.infosystems.www.authoring.servers.misc>.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Ben Bacarisse]

Thomas 'PointedEars' Lahn <Point...@web.de> writes:

> Ben Bacarisse wrote:
<snip>
>> [...] You can put it up for only as long as it takes to take a

>> copy of the output. This is probably safe enough, especially if make it
>> "un-guessable". Give the file a name like fd6621c78b399e93c0ae185e.php
>> and you will be fine. (Obviously don't use *that* name -- I've just
>> made it public!).
>
> There is no such thing as “un-guessable”. For example, an attacker can
> easily generate an HTML document or documents with links of permutations of
> URIs and have robots like Googlebot add the working URIs to its index. Once
> it is indexed, it can be found using the “site:…” filter of Google Search,
> for example.

In what sense is that a guess?

<snip>
--
Ben.