After confirming this was true I also determined that the default block for .htxxxx files would fail if you typed them in uppercase in the url i.e http://some.macosx.server/.HTACCESS. After considering the filter shown below I thought why not just block all hidden files and so did the following.. <FilesMatch "^\."> Order allow,deny Deny from all </FilesMatch> This matches any file that starts with a period and seems to do the trick. I can't think of an instance where you'd want a hidden file to display on the web. Am I missing something? -- Paul Lieberman lieb@sou.edu Systems Engineer 541-552-6962 Computing Services Center Southern Oregon University Ashland, OR > Jacques Distler <distler@golem.ph.utexas.edu> 09/10/01 07:02AM >>> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [Originally posted to <http://www.macintouch.com/mosxreaderreports46.html>] > > We've already seen the security problems (or potential problems) in Apache > on MacOSX associated to the case-insensitivity of HFS+. By exploiting the > case-insensitivity of HFS+, an attacker can evade Apache's access controls. > > Using mod_hfs (which takes care of case-insensitivity in directory names) > and using <FilesMatch> (with well-chosen regular expressions) instead of > <Files> directives (to take care of case-insensitivity in filenames), we can > "cure" the case-insensitivity problem and restore Apache's access controls. > > But there's another gotcha lurking. > > You typically don't want people to be able to obtain a list of files in your > web directory. To allow them to obtain such a list, you explicitly have to > > 1) NOT have an index.html file in the directory > 2) include an Options Indexes directive among the access controls for that > directory > > Or you could just run MacOSX. > > The Finder creates an invisible file, ".DS_Store" in each directory which > contains (among other binary gobledygook) a list of files in the directory. > > So, if you have EVER viewed a web directory in the Finder, an attacker can > just retrieve > > http://your.mac.com/some_directory/.dS_store > > to learn what files are in that directory. > > The solution is, again, to use a <FilesMatch> directive in httpd.conf to > forbid retrieval of this file: > > # The Finder creates an invisible .DS_Store file in each directory. > # For 'no-index' access controls to be effective, we had better forbid > # retrieval of that file as well. Note that we have to protect > # against the same case-insensitivity bug as above. > # > <FilesMatch "^\.[Dd][Ss]_[Ss]"> > Order allow,deny > Deny from all > </FilesMatch> > > Note the regular expression to take care of case-insensitivity :-). And, of > course, you need to > > sudo apachectl restart > > when you're done. > > Of course, the real question is: why was this file created world-readable > in the first place? > > But then, Apple has taken a REALLY lax attitude about file permissions > throughout all of MacOSX. > > More on the security implications of that some other time . . . > > Jacques Distler > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (Darwin) > Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc > > iD8DBQE7nMfSnyqPIXpYcjcRAlOvAJ9AVuC9L3AAdUfokFBrSlN113JfbgCeKoep > uORBZBGqMIR6VW3PVFO39P4= > =IG6Q > -----END PGP SIGNATURE-----
