Front Page Extensions – security considerations

Front Page Extensions – security considerations

I don’t claim to be a security expert.  So treat everything I write here accordingly.

You’ve come a long way baby

FrontPage 98 was notorious for security exploits.  There were many holes found in the Front Page server extensions.  As far as I know, all of these concerns have been addressed with FrontPage 2000.  I’ve been speaking with someone who’s been working pretty hard at finding holes in it and hasn’t been able to find any.  People will continue to roll their eyes and claim FP is full of holes.  That’s OK.  They’re just repeating old news and aren’t up with the latest and greatest.

As a comparison, sendmail, at one time full of many bugs and well known exploits, now delivers most of the world’s email.  But memories die hard.  Some people still claim qpopper is buggy.  But that’s old news too.  It’s been fixed.

Shell access to your webserver

If you provide shell accounts on your webserver, you should be aware of the file permission considerations surrounding the default installation.  By default, anyone with a shell account can do this:

$ more /path/to/web-site/_vti_pvt/service.pwd
# -FrontPage-
testwebsite:1EWXvqbvr4rx2

There you have a user/password combintion.   It’s easy enough for someone to feed that into a password cracker.

If you don’t allow shell access to your box, this isn’t an issue.

If you do allow shell access to your box, here is the idea I’ve been playing around with.  It consists of two main points.

1. chgrp the files to <user id>:<webserver group> so that the user owns the file, but the webserver can access the files.
2. chown the files so that they are not world readable.

This strategy relies on three main points.

1. Since the user owns the files, they can update, delete, etc as they wish.
2. The files belong to the webserver group (in my case, this group is www), which is what apache runs under.  This means the webserver can access the files as needed.
3. All files have permissions such as 640 or 750 so that everyone else cannot access the files.

The only drawback I can see with this strategy is that the users can change permissions to give world access to files.  To conteract this possibility, a script can be run daily to search for such files.  I’ve been given such a script and I’m going to test it and report back.  Watch this space.

I’m still looking for more comments on this strategy.   Please let me know your views.

Password security

Tell your users to keep their FrontPage passwords different from their shell passwords.   If the FrontPage security is compromised, at least shell access has not been given away.

Restrict your web site directory

There are special things you need to consider if you are placing your webpages outside the regular document root of /usr/local/www.  The following extract from http.conf is what has been recommended to me as being able to secure such directories with respect to FrontPage.

<Directory "/www">
    Options Indexes FollowSymLinks ExecCGI
    <IfDefine FRONTPAGE>
        AllowOverride AuthConfig Limit Indexes Options
    </IfDefine>
    <IfDefine !FRONTPAGE>
        AllowOverride None
    </IfDefine>
    Order allow,deny
    Allow from all
</Directory>

As always, if you’re figured out something better, or you see a hole in the above, please add your comments.