Web form w/ Access DB Security

[wwcoop]

I am deploying a web form developed in VB.NET
using an OleDB connection to an Access DB.
I am able to deploy the app with the DB residing
in the same folder to the web server and get it
running.

I now want to change the configuration so that
the the DB does NOT reside anhywhere in the web
directory. (For security reasons.)

I tried setting up a DSN in the ODBC Data Source
Administrator, however I now know that
Visual Studio does not support use of a DSN in
the IDE (at least not comprehensively)--
you have to use a code behind which
can be rather nasty.
( See [url]http://www.developerfusion.com/show/3581/[/url] )

Question: How would I access this DB if it is on another
computer on the same network? OR, can I put the DB
outside of the web directory on the web server and
still be able to access it? What configuration should I
use?

Thanks!

--
Will Cooper
Application Programmer

[Mary Chipman [MSFT]]

If security is a genuine concern, then DO NOT use an Access database.
Access was originally designed and conceived to be a desktop database
over 12 years ago, and it hasn't changed all that much in the
meantime. It's so-called security features have been hacked a long
time ago, and it does not function well as a data store for a web
application. I'd advise looking into SQL Server/MSDE as a back end for
your web app.

That being said, for Access you should be using the OleDb provider,
not ODBC. DSNs are another huge security hole since the user ID and
password is stored in clear text. You would need to grant the
appropriate ACLs to the ASPNET worker process account (Windows) on the
file share that the .mdb and .mdw reside on.

--Mary

On Wed, 16 Mar 2005 06:25:03 -0800, wwcoop
<wwcoop@discussions.microsoft.com> wrote:

>I am deploying a web form developed in VB.NET
>using an OleDB connection to an Access DB.
>I am able to deploy the app with the DB residing
>in the same folder to the web server and get it
>running.
>
>I now want to change the configuration so that
>the the DB does NOT reside anhywhere in the web
>directory. (For security reasons.)
>
>I tried setting up a DSN in the ODBC Data Source
>Administrator, however I now know that
>Visual Studio does not support use of a DSN in
>the IDE (at least not comprehensively)--
>you have to use a code behind which
>can be rather nasty.
>( See [url]http://www.developerfusion.com/show/3581/[/url] )
>
>Question: How would I access this DB if it is on another
>computer on the same network? OR, can I put the DB
>outside of the web directory on the web server and
>still be able to access it? What configuration should I
>use?
>
>Thanks!

[wwcoop]

Thanks for your input. I agree that Access is not the way to go securitywise...
I actually worked my issue out as follows:
I was able to map a network drive from the web server
to the server where the DB resides, in this case it was
W:\testdb as the mapped drive path.
This doesn't work when you try to compile and run
in Visual Studio, however it works fine once you move
the app over to the web server. The ASP.NET app can
call the DB and execute against the DB fine and the DB is
still protected since it does not reside on the web server.
The ASP.NET coding contains password protections against
unwanted users hacking the DB...

Thanks

[Mary Chipman [MSFT]]

The danger with using Access as a data store isn't so much with users
coming through your ASP.NET front-end. The weakness lies in the fact
that you have granted read/write/delete on the file share that the mdb
resides on, which is accessible to the aspnet worker process (by
default a least-priviledged account with otherwise restricted access).
You have to assume that a savvy attacker will be able to do an end run
around your app. So any data stored in the mdb should be considered to
be unsecured and at risk, and the overall system vulnerable to attack.
As long as you have other measures in place to monitor and log your
web server, you might be able to get away with it. But never assume
that because your client app contains password protections that you
are secure--you're not.

--Mary

On Wed, 16 Mar 2005 08:53:06 -0800, wwcoop
<wwcoop@discussions.microsoft.com> wrote:

>Thanks for your input. I agree that Access is not the way to go securitywise...
>I actually worked my issue out as follows:
>I was able to map a network drive from the web server
>to the server where the DB resides, in this case it was
>W:\testdb as the mapped drive path.
>This doesn't work when you try to compile and run
>in Visual Studio, however it works fine once you move
>the app over to the web server. The ASP.NET app can
>call the DB and execute against the DB fine and the DB is
>still protected since it does not reside on the web server.
>The ASP.NET coding contains password protections against
>unwanted users hacking the DB...
>
>Thanks

[Pril]

You can use this scenario:
-create new user
-use file system security and give this user read/write access to mdb
database (all other users are without this permissions)
-in asp application open new process as this user
-access to database

lp, pl

"Mary Chipman [MSFT]" <mchip@online.microsoft.com> wrote in message
news:2r7j31h0q56opv6hogjnsllesr2bsd803r@4ax.com...

> The danger with using Access as a data store isn't so much with users
> coming through your ASP.NET front-end. The weakness lies in the fact
> that you have granted read/write/delete on the file share that the mdb
> resides on, which is accessible to the aspnet worker process (by
> default a least-priviledged account with otherwise restricted access).
> You have to assume that a savvy attacker will be able to do an end run
> around your app. So any data stored in the mdb should be considered to
> be unsecured and at risk, and the overall system vulnerable to attack.
> As long as you have other measures in place to monitor and log your
> web server, you might be able to get away with it. But never assume
> that because your client app contains password protections that you
> are secure--you're not.
>
> --Mary
>
> On Wed, 16 Mar 2005 08:53:06 -0800, wwcoop
> <wwcoop@discussions.microsoft.com> wrote:
>

> >Thanks for your input. I agree that Access is not the way to go

securitywise...

> >I actually worked my issue out as follows:
> >I was able to map a network drive from the web server
> >to the server where the DB resides, in this case it was
> >W:\testdb as the mapped drive path.
> >This doesn't work when you try to compile and run
> >in Visual Studio, however it works fine once you move
> >the app over to the web server. The ASP.NET app can
> >call the DB and execute against the DB fine and the DB is
> >still protected since it does not reside on the web server.
> >The ASP.NET coding contains password protections against
> >unwanted users hacking the DB...
> >
> >Thanks

>

[Mary Chipman [MSFT]]

Yes, you can do that, but don't think of it as "secure". This user has
read/write/delete on the file share and there is nothing preventing
the user from making off with, or destroying, the entire mdb file.
This is the fundamental security weakness with Access, which, unlike
SQL Server/MSDE requires granting ACLs on a file share in order to
work with the data. With a server database, the actual files are not
vulnerable unless you deliberately shoot yourself in the foot by
allowing logins with elevated permissions.

--Mary

On Thu, 17 Mar 2005 22:03:16 +0100, "Pril" <pril@NOSPAMemail.si>
wrote:

>You can use this scenario:
>-create new user
>-use file system security and give this user read/write access to mdb
>database (all other users are without this permissions)
>-in asp application open new process as this user
>-access to database
>
>lp, pl
>
>"Mary Chipman [MSFT]" <mchip@online.microsoft.com> wrote in message
>news:2r7j31h0q56opv6hogjnsllesr2bsd803r@4ax.com.. .

>> The danger with using Access as a data store isn't so much with users
>> coming through your ASP.NET front-end. The weakness lies in the fact
>> that you have granted read/write/delete on the file share that the mdb
>> resides on, which is accessible to the aspnet worker process (by
>> default a least-priviledged account with otherwise restricted access).
>> You have to assume that a savvy attacker will be able to do an end run
>> around your app. So any data stored in the mdb should be considered to
>> be unsecured and at risk, and the overall system vulnerable to attack.
>> As long as you have other measures in place to monitor and log your
>> web server, you might be able to get away with it. But never assume
>> that because your client app contains password protections that you
>> are secure--you're not.
>>
>> --Mary
>>
>> On Wed, 16 Mar 2005 08:53:06 -0800, wwcoop
>> <wwcoop@discussions.microsoft.com> wrote:
>>

>> >Thanks for your input. I agree that Access is not the way to go

>securitywise...

>> >I actually worked my issue out as follows:
>> >I was able to map a network drive from the web server
>> >to the server where the DB resides, in this case it was
>> >W:\testdb as the mapped drive path.
>> >This doesn't work when you try to compile and run
>> >in Visual Studio, however it works fine once you move
>> >the app over to the web server. The ASP.NET app can
>> >call the DB and execute against the DB fine and the DB is
>> >still protected since it does not reside on the web server.
>> >The ASP.NET coding contains password protections against
>> >unwanted users hacking the DB...
>> >
>> >Thanks

>>

>