On 12/3/2012 3:07 PM, Igor Cicimov wrote:
>
> On 04/12/2012 5:41 AM, "Ben Johnson" <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> Hello, everyone,
>>
>> I am able to view .htaccess and .htpasswd files on my development server
>> from within a Web browser.
>>
>> My understanding is that the following configuration directive, which is
>> included in the default configuration file, should prevent this:
>>
>> -----------------------
>> #
>> # The following lines prevent .htaccess and .htpasswd files from being
>> # viewed by Web clients.
>> #
>> <Files ".ht*">
>> Require all denied
>> </Files>
>> -----------------------
>>
>> I have made very few changes to the default configuration file; it is
>> almost entirely "stock".
>>
>> Apache's mod_info output mentions the string "*.ht" only once, on line
>> 291 (apologies for the text wrapping), so it seems that the directive is
>> indeed effective:
>>
>> -----------------------
>> Module Name: mod_authz_core.c
>> Content handlers: none
>> Configuration Phase Participation: Create Directory Config, Merge
>> Directory Configs, Create Server Config
>> Request Phase Participation: Check Access, Verify User Access
>> Module Directives:
>> <AuthzProviderAlias> - container for grouping an authorization
>> provider's directives under a provider alias
>> Require - specifies authorization directives which one must pass (or
>> not) for a request to suceeed
>> <RequireAll> - container for grouping authorization directives of which
>> none must fail and at least one must pass for a request to succeed
>> <RequireAny> - container for grouping authorization directives of which
>> one must pass for a request to succeed
>> <RequireNone> - container for grouping authorization directives of which
>> none must pass for a request to succeed
>> AuthMerging - controls how a <Directory>, <Location>, or similar
>> directive's authorization directives are combined with those of its
>> predecessor
>> AuthzSendForbiddenOnFailure - Controls if an authorization failure
>> should result in a '403 FORBIDDEN' response instead of the
>> HTTP-conforming '401 UNAUTHORIZED'
>> Current Configuration:
>> In file: C:/Program Files/apache/conf/httpd.conf
>> 233: <Directory />
>> 235: Require all denied
>> : </Directory>
>> 251: <Directory "C:/Users/Ben/Documents/Apache">
>> 276: Require all granted
>> : </Directory>
>> 291: <Files ".ht*">
>> 292: Require all denied
>> : </Files>
>> 383: <Directory "C:/Program Files/apache/cgi-bin">
>> 386: Require all granted
>> : </Directory>
>> In file: C:/Program Files/apache/conf/auth.conf
>> 19: <Location />
>> 23: Require valid-user
>> : </Location>
>> In file: C:/Program Files/apache/conf/httpd.conf
>> 638: <Location /server-info>
>> 639: Require all granted
>> : </Location>
>> -----------------------
>>
>> I must be overlooking something obvious here, and any help is much
>> appreciated.
>>
>> Thank you!
>>
>> -Ben
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
> <mailto:[email protected]>
>> For additional commands, e-mail: [email protected]
> <mailto:[email protected]>
>>
> Remove Indexes from Options. Also remove the world readable permission
> from the files.
>
Thank you for the reply, Igor.
I have already removed the "Indexes" option on the server in question
(both for the document root and at the "/" location), which does not
change this behavior.
While I do see your point about setting the .htaccess and .htpasswd
files' permissions to prevent world-readability, I do not wish to rely
on the permissions being set correctly.
In Apache 2.2, I never had a problem with this; regardless of the files'
permissions, Apache always returned a 403 response when ".ht*" files
were requested.
While troubleshooting, I tried the following two approaches, just to see
if I was able to deny access to different types of files, and neither
seems to have any effect:
--------------------------
<Files "index.php">
Require all denied
</Files>
<FilesMatch "index\.php$">
Require all denied
</FilesMatch>
--------------------------
Any other ideas as to why none of these are effective?
Thanks again,
-Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
