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

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-

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

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 !FRONTPAGE>
        AllowOverride None
    Order allow,deny
    Allow from all

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

2 thoughts on “Front Page Extensions – security considerations”

  1. Fedor (Ted) Gnuchev

    Thanks for very good article!

    You may consider changing to "unique" scheme – with every user
    getting personal UID==GID.
    Also requires User and Group directives in virtual host sections of httpd.conf and correct suexec installation.

    (Apply with a grain of salt 🙂


    – you’ll be able to track who’s running what instead of anonymous apache user. Trust me, it is helpful 🙂 if you allow them to run perl scripts and give them freedom to use half of the CPAN modules. Some users will mistake you for jellyhead instead of being grateful for being given "no crippleware" tools.

    – users will be unable to break out of 750 permission mask on home dir.

    – matches PHP security features – you’ll need them to stop abuse: php is as dangerous as any good tool for "cripled" users.


    – you’ll have to take care of adding User and Group to every
    virtual host section you have.

    – you’ll have to make sure suexec is properly installed.

    – users will stop telling that you suck after couple of unsuccessuful attempts to break your security scheme 🙂

  2. I’ll be commenting on this topic. Hoping to bring it up to date a bit. FPX is now 2002 (v5) and many security concerns are gone (or so Redmond says). The general recommendation is not to use FPX in a production environment. However, business pressures can be tough to fight.

Leave a Comment

Scroll to Top