🚀 go-pugleaf

Hi all,

I'm reading L. Stein's Web Security book and I have some questions
regarding .htaccess on the commerce server that isn't discussed
explicitly at the Best FAQ.

I'm writing out excerpts from the book with my questions interspersed...

(Sorry if this is a long post, but I wanted to give my questions a
context. And besides, I can imagine there is some stuff worth interest
to some best.www posters)
==================================================

Restricting by Host Name and IP address Restriction in the Apache Server
page 249

Apache and other NCSA httpd derivatives use a global access
configuration file, 
"/usr/local/etc/httpd/conf/access.conf", to set directory access
policies for each part of the directory tree.  Optional per-directory
access control files (usually named .htaccess) can be placed inside the
directories themselves in order to fine-tune access policies without
having to "access.conf" and restart the server.  If you run a site with
multiple virtual hosts, each host can have a different "access.conf" and
a completely different set of access control rules.

[...con't]

====

Question 1: Is this the case of each virtual host having an
"access.conf" on Best's servers?  And if so, can I access my own
"access.conf" for my domain? or is this a root access only scenario? (I
am guessing that it is, but I thought I would pose the question just the same.)

======

[con't...]

<Files>
page 251

<Files> and </Files> directives can be used to filter access to files
based on their names.  The directive's argument is a pattern match for
the server to apply to the physical path of a requested document.  If a
match is found, the access restrictions are applied.  For example, you
can restrict access to all files named "secret.html" using a directived
like <Files */secret.html>/  In addition to standard wildcards, newer
versions of Apache support matching based upon regular expressions.  ...
<Files> can also be used within an ".htaccess" file.  When used in this
way, the server strips off the portion of the path up to and including
the current directory before attempting to apply the pattern match.

======

Q2: Does our version of Apache/Stronghold support this feature for
.htaccess files?

======

<Limit>

The <Limit and </Limit> directives establish the access policy for this
directory.  The format is <Limit meth1 mth2 ...>, where each of the
parameters is one of the HTTP access methods GET, POST, PUT or DELETE.
Clients thet try to use the listed method will be restricted according
to the rules listed within the section.  GET is the method commonly used
to retrieve normal documents, POST is used for sending data to sertain
executable scripts, and the others are not widely used.  Ordinarily,
you'll need to restrict only GET requests.  you should restrict POST, as
well for directories that contain executable scripts. Because it doesn't
hurt, I recommend limiting everthing, including PUT and DELETE, in the
interest of avoiding nasty surprises when these methods become commonly
used at some future date.

======

Q3: Does our version of Apache/Stronghold support PUT or DELETE methods
yet? and if my cgi's are mixed with html and/or text files, how should I
restrict both GET and POST for a directory's .htacess file if said
directory that contains a sundry mix of files types? Any comments?

======

Deny From and Allow From

Within each <Limit> section, you can put any number of "order", "deny
from", and "allow from" directives.  To deny access to one or more hosts
or domains, use the "deny from" directive (yes, the "from" really is
part of the directive):

	deny from host1 host2 host3 ...

Each list host can be a fully qualified host name, such as
"monkey.zoo.org"; a domain name, such as ".zoo.org"; a full numeric IP
address, such as 18.128.12.1; a partial IP address such as 18.128.12; or
the word "all".  Hosts can be listed on one long line or in multiple
short directives.  Apache matches numeric IP addresses and domain names
in slightly different ways.  When you give it something that looks like
a partial IP address, the server tries to match it from left to right. 
The address 18.128.12 will match 18.128.12.1 and 18.128.12.2, but not
192.18.128.12.  Something that looks like a domain name will match from
right to left: ".zoo.org" will match "monkey.zoo.org" and
"tapir.zoo.org", but not "monkey.zoo.org.edu".

The "allow from" directive has the oppostie effect, granting access to
the host or hosts listed.  The order in which the allow and deny
directives are processed is important because later directives override
earlier ones.  The "order" directive, which comes in three forms,
controls this.

	order deny,allow
	order allow,deny
	order mutual-failure

The first form processes the deny directives first, followed by the
allow directives.  Use it when you want to deny access to a number of
hosts (such as "all" or an entire domain), and then selectively turn
access back on.  Unless you specify "deny from all", all hosts not
specifically mentioned are allowed access.  This form is the default
when order isn't specified.

The second form does the opposite, processing all the allow directives
first, then the deny directives. Use it for cases when you want to allow
access to most members of a domain and then exclude particular hosts.
Like the previous form, hosts not mentioned in either the allow or the
deny list are allowed access by default.

The third form, "mutual-failure", requires a host to be mentioned either
in the allow list or the deny list. Any host that does not appear on one
list or the other will be denied. This is probably the form that is
safest to use, because there is no chance of a host slipping through the cracks.

Use this template when you want to allow everyone in except a few people
who've been giving you trouble.

	<Location />
		<Limit GET POST PUT DELETE>
			order mutual-failure
			allow from all
			deny from .crackers.ltd .phreaks.com dorm3.bigU.edu
			deny from 18.157.5
		</Limit>
	</Location>

An here's one to use when you want to deny access to everyone except for
a few trusted hosts.

	<Location />
		<Limit GET POST PUT DELETE>
			order mutual-failure
			deny from all
			allow from friend.com
			allow from 18.157.0.5 18.157.0.22 192.235.1.3
		</Limit>
	</Location>

Some systems have trouble retrieving the fully qualified host name for
the server host and other local machines.  If this affects you, you may
have to use the numeric partial IP address of your domain in order to
allow access by local hosts. On some systems, adding the line "allow
from localhost" will allow you to access a protected directory using a
browser running on the server machine itself.  Also note that in order
for the DNS-based access control to work at all, the server must be
performing DNS lookups on incoming connections.  Many sites have turned
off DNS lookups for performance reasons.

======

Q4: I'm assuming that Best servers do lookups and that retrieving host
names from local machines isn't a problem, right? And do we need to use
the "allow from localhost" directive at all?

======

When an access restriction is applied to a directory, it applies to all
its subdirectories as well, unless "access.conf" contains a more
specific entry. Access restrictions can also be modified by
per-directory ".htaccess" files located in the directory itself. These
files should be world-readable and contain whatever you would ordinarily
put within a <Location> or <Directory> section.

======

Q5: Usually perms on Best servers are recommended to set the world
permission bit at "0".  How should .htaccess file perms be set in this
case? Should they still be set at "0" for the world perms bit?

======

For example, to arrange restrictions so that only browsers connecting
from hosts in the "capricorn.org" domain can gains access to the
"/local/web/confidential" directory, you might create a file named
.htaccess in that directory containing

	<Limit GET POST PUT DELETE>
		order mutual-failure
		deny from all
		allow from .capricorn.org
	</Limit>

Although .htaccess files are convenient to use because you can change a
directory's access restrictions without restarting the server, they
complicate matters if overused. Instead of being centralized in a single
configuration file, your site's access policy is scattered among dozens
of files.  Another problem with the files is that they're created in the
same directories as HTML files.  This means that the web authors at your
site will have the ability to add and modify access control policies. 
If this is not what you want, you can eliminate the ability of .htaccess
files to override access policies by adding an entry like this the the
main "access.conf"

	<Location />
		AllowOverride FileInfo
	</Location>

======

Q6: As is written earlier <Location > is for access.conf, but I'm
curious if the slash following <Location... (which must denote "all
files under that directory") if similar notation can be made for
directory and file, maybe a non-question, but I'd like to ask it just
the same:

	<Directory />
		directives
	</Directory>

or 

	<File />
		directives
	</File>

======

This allows authors to use .htaccess files to tweak the MIME types of
files within their directories and perform other innocent
customizations, but does not give them permission to change access
control policies.

There's also an odd security loophole in both Apache and other
derivatives of NSCA httpd.  Remote users can fetch and view the contents
of .htaccess files by simply requesting their URLs.  This is undesirable
since these files may contain the names of confidential files and
addresses of internal hosts.  To prevent this, add the following to the
main access.conf file:

	<Files */.htaccess>
		<Limit GET POST PUT DELETE>
			order mutual-failure
			deny from all
		</Limit>
	</Files>

After changing DNS or IP address restrictions, you should be sure to
test them, if you can, by attempting to gain access to the server from
allowed and forbidden machines.

======

Q7: I would imagine this is nothing to worry about, since the book I am
quoting from was published in '97 and every Best engineer already knows
this.  However, I am curious how we can verify how our .htaccess files
are working.  Is there a common method for troubleshooting this?

======

BTW: I'd be into posting the section of this same chapter regarding
"Access Control on User Name and Password" if anyone is interested in
opening up a thread about it.  Specifically if there is an equivalent to
.htaccess for the realms.conf if I'd like to implement group-like
permissions to my websites.

Thanks in advance!
-- 
madame philosophe
mp@mkt2mkt.com
"Have you thought lately?"