Web form w/ Access DB Security

Discussion in 'ASP .Net Security' started by wwcoop, Mar 16, 2005.

  1. wwcoop

    wwcoop Guest

    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 http://www.developerfusion.com/show/3581/ )

    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
     
    wwcoop, Mar 16, 2005
    #1
    1. Advertising

  2. 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
    <> 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 http://www.developerfusion.com/show/3581/ )
    >
    >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!
     
    Mary Chipman [MSFT], Mar 16, 2005
    #2
    1. Advertising

  3. wwcoop

    wwcoop Guest

    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
     
    wwcoop, Mar 16, 2005
    #3
  4. 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
    <> 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], Mar 17, 2005
    #4
  5. wwcoop

    Pril Guest

    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]" <> wrote in message
    news:...
    > 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
    > <> 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, Mar 17, 2005
    #5
  6. 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" <>
    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]" <> wrote in message
    >news:...
    >> 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
    >> <> 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], Mar 18, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?UWFqdXNzaQ==?=

    How to create a web form like MS access form using asp.net??

    =?Utf-8?B?UWFqdXNzaQ==?=, Dec 27, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    761
    =?Utf-8?B?UWFqdXNzaQ==?=
    Dec 27, 2004
  2. Aaron
    Replies:
    1
    Views:
    369
    John C. Bollinger
    Aug 4, 2003
  3. slc
    Replies:
    0
    Views:
    435
  4. huoge
    Replies:
    0
    Views:
    186
    huoge
    Jul 11, 2003
  5. Hans Östlund
    Replies:
    1
    Views:
    180
    Alessandro Zifiglio
    Feb 5, 2004
Loading...

Share This Page