[thelist] ASP: FileSystemObject.FileExists

Ken Schaefer ken at adOpenStatic.com
Wed Apr 14 23:42:34 CDT 2004

From: "Maximillian Schwanekamp" <anaxamaxan at neptunewebworks.com>
Subject: RE: [thelist] ASP: FileSystemObject.FileExists

: >Filesystem Security holes?!? Please elaborate.
: >a) put the Access .mdb file outside the webroot (there's
: >no requirement that
: >it be inside the webroot in the first place)
: >b) use IIS to restrict the permissions of the same folder
: While it's true that you can (and should) put the .mdb outside
: the webroot, in practice (in my admittedly limited experience!)
: it usually *is* in the webroot, at least in a shared hosting
: environment.  IIRC, Access  usually runs under IUSR, so it
: gets write permission in order to create a lock file.
: Perhaps I am mistaken on that point.  In retrospect, I
: probably am.  Anyway that's what I meant by "filesystem
: security hole."  Sorry.  Bad wording.

This is all true, especially as you say, in a hosting environment. Unless
you use a middleware COM component that runs under a separate user context
then ADO/OLEDB objects will run under the account IIS is impersonating (eg

What should happen is that the host provides a secured directory (eg
Frontpage creates a /fpdb directory) that does not serve requests via HTTP.
ASP.Net does something similar with the /bin directory that houses .Net

That said, allowing Write permissions does increase the attack surface,
however I don't see it as a "hole" per se as there isn't any automatic way
to exploit it.

: >I think this is pretty much the same for just about any database.
: >The DBMS must be able to write to the database file. And most
: >decent DBMS have transaction logs as well
: But those RDBMSs *always* have their data files outside the webroot,

Possibly, but an Access database can be configured to be outside the webroot
as well.

I'm not trying to argue that mySQL or SQL Server has the same level of
security that Access does - far from it! I just don't think Access is as bad
(in a properly configured environment) as some people say.

: >I'd be really interested to know what you think these holes with
: >"overliberal user impersonation capabilities" are.
: SoftArtisans' FileManager has a "LogonUser" method that allows
: the script to switch user contexts while executing an ASP script.
: It allows the script to act with the permissions of any user for
: whom the username/password are supplied. In some scenarios
: (such as an IIS application running in high isolation, IIRC) using that
: method requires granting IWAM the right to act as part of the OS,
: which seems potentially dangerous.  The method is one of
: the perks of using FileManager in place of the regular FSO.  This seems
: "overliberal" to me.

Um, you have a username and a password. You run the website inside the
InetInfo.exe process as LocalSystem (or you grant the process identity
IWAM_<machinename> permissions to run as part of the operating system). And
you think this is over-liberal? You have to /deliberately/ configure IIS to
do this, and you have to know the username and password of the user you want
to impersonate.

I could accomplish the same thing by just denying anonymous access, and
forcing authentication. I supply a username and password, and the page will
run under that context.

: This issue came up with a client some 18 months back,
: way before IIS6.  They were having security problems,
: and Microsoft Security folks brought this up for us.
: A member of that same MS team had suggested
: to us at the time that IIS6 would not allow this sort of
: arbitrary user context switching within a web script.
: Dunno if that's true or not!

If you change the worker process identity to LocalSystem, of course you can
do this. LocalSystem can do anything, including replacing the OS binaries.
But, as with IIS5 or 4, you had to deliberately configure your OS in a
less-secure manner for this to work.

I suppose it would be easier in IIS4/5 to do this as "in-process" websites
ran in the InetInfo.exe process, which by default runs as LocalSystem.
However, by default, websites where not placed in-process. On IIS5.0, they
were configured (by default) as the using "Medium (Pooled)" application
protection. This meant that they ran inside dllhost.exe, which has the
IWAM_<machinename> as the process identity (you could change this in
Component Services if you wanted to), which is a much less privileged


More information about the thelist mailing list