All your methods are well placed and nicely described. The best security
(including security by obscurity) is ensuring the file isn't in your
document/cgi-bin root for web browsers. Par example:
/home/httpd/html - Document Root
/home/httpd/cgi-bin - CGI Root
/home/httpd - Location of OpenSRS.conf
If anyone can get around that, it wont matter where on your system you put
stuff :)
Mike Bilow wrote:
>
> I think that the appropriate security philosophy is to have a well-defined
> wall separating public and private data. Anything which is released under
> GPL, or which could be expected to be known by a large number of people,
> should be regarded as public and no effort should be invested in trying to
> hide or obscure such things.
>
> Various distributions of Apache have security enhancements above and
> beyond the basics. Here is one of mine that you get if you are running
> Debian and install the Apache package:
>
> # Do not allow retrieval of the override files,
> # a standard security measure.
> <Files .htaccess>
> order allow,deny
> deny from all
> </Files>
>
> This is the correct way to secure something you do not want publicly
> accessible under any circumstances and which has a constant filename which
> can be expected to be generally known. In the case of OpenSRS, for
> example, "OpenSRS.conf" should be protected like this:
>
> <Files OpenSRS.conf>
> order allow,deny
> deny from all
> </Files>
>
> In general, files such as "OpenSRS.conf" which are intended to be read by
> the executing CGI and never actually sent to a browser over the wire
> should be maintained outside of the document root. Where that is not
> possible, as for example when the CGI program is subjected to a chroot,
> then mechanisms such as the "Files" directive should be employed.
> Obviously, ".htaccess" files must be within the document root, which is
> why the restriction shown was added to the Debian Apache package.
>
> Likewise, the proper way to turn off indexing is to do this whenever
> enabling CGI as a matter of course:
>
> <Directory /var/www/cgi-bin/>
> Options -Indexes +ExecCGI
> </Directory>
>
> "ScriptAlias" is not more secure against the outside world. Its purpose
> is to provide added security against authors of web site content who may
> write compromising CGI scripts without realizing the effect. In theory,
> placing all CGI scripts into a central repository where they can be
> carefully checked by the system administrator before being made available
> for public access should enhance security, but I have yet to see any
> installation where the use of this technique proved politically viable.
> (Besides, "Script/ScriptAlias" does not do what you think it does: it
> actually only sets the default, and what you want is "ForceType.")
>
> Merely defining things as scripts when they are not, either by abusing the
> "Script/ScriptAlias" directive or by fooling Apache with ".cgi" filenames,
> is a very wrongheaded approach. The most likely result of this sort of
> thing is confusing oneself into introducing security holes. It is likely
> to be better for security to keep the system as clean as possible.
>
> Apache provides a set of three similar tag directives for controlling
> access within document space. These are:
>
> 1. "Directory"/"DirectoryMatch" -- used to restrict access on the basis of
> of the path on the host filesystem;
>
> 2. "Location"/"LocationMatch" -- used to restrict access on the basis of
> the URL, which does not necessarily have a direct correspondence to the
> host filesystem;
>
> 3. "Files"/"FilesMatch" -- used to restrict access on the basis of the
> filename on the host filesystem.
>
> Anyone interested in the details is encouraged to read up on them at:
>
> http://www.apache.org/docs/mod/directives.html
>
> -- Mike
>
> On Wed, 29 Mar 2000, Grant Kaufmann wrote:
>
> > Bhavin Turakhia (bhavindom@directi.com) wrote:
> >
> > > 1) Rename all your files - anyone using the opensrs knows all the
> > filenames
> > > and therfore leves a security hole
> > The cgi files are called by the web-browser anyway. Renaming manage.cgi to
> > manager.cgi won't help, because the user can see the new name in the
> > browser. Assuming that the attacker had found a way to read any file that
> > the web-server user could read. They could read the cgi, and get the path
> > for the config files.
> >
> > > 2) if you have directory browsing allowed then put an index.html in all
> > the
> > > directories something which does not come when you untar the opensrs files
> > Rather just turn directory browsing off for your OpenSRS document tree.
> > Also, if its in a Script directory, it won't do directory listings anyway.
> >
> > > 3) rename opensrs.conf to opensrs.cgi so that it cannot be read from the
> > > browser if you have it in your normal http path
> > This will only work if you have set up your webserver to treat files with a
> > .cgi extention as a CGI, rather than the more secure ScriptAlias.
> >
> > The problem with Bhavin's suggestions is that although they might appear to
> > add a level of security, they're really just making it slightly harder by
> > obscuring the implementation details. Security through obscurity doesn't
> > work, to secure OpenSRS you will need to isolate the cgi's from the
> > configuration and to ensure that the entire system can only be accessed in a
> > controlled manner.
> >
> > --
> > Grant
--Charles Daminato OpenSRS Technical Operations chuck@opensrs.org
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT